Partner portals and cybersecurity dashboards need customer boundaries throughout each request and background job. A tenant selector is only a user-interface control.

An analyst may work across several customers. A connector may collect data from one customer. Neither should receive unrestricted platform authority.

This guide follows a hypothetical evidence export from sign-in to download. Use it to review memberships, worker permissions, and access removal.

A supplier-platform incident led to an extortion demand

In July 2026, The Record reported a CHF10 million demand against Stadler. It quoted the company's account of compromised credentials affecting a supplier's file-sharing platform.

Stadler said its own systems were unaffected and production continued. It refused payment. Read the report and linked company statement.

The report supports a discussion about partner access and shared information. It does not identify a tenant-isolation failure or establish the controls that would have prevented the incident.

Map the actor, customer, and workload

A tenant is a separate customer or organisation boundary. One person can have memberships in several tenants without receiving access to all platform data.

Consider a hypothetical cybersecurity service used by a managed security provider. Analysts investigate alerts for assigned customers and export selected evidence.

Actor	Proposed authority	Boundary
Customer user	View their organisation's permitted cases	Current customer membership
Partner analyst	Investigate assigned customer cases	Explicit customer and case assignments
Partner administrator	Manage approved analyst assignments	No automatic right to every evidence file
Platform support	Perform a defined support task	Separately approved customer access
Connector workload	Collect specified customer data	Dedicated credentials and resource scope
Export worker	Produce one approved export	Recorded customer, resources, and purpose

Treat user permissions and workload permissions separately. A background worker should not inherit a person's entire administrative role.

OWASP's multi-tenant guidance discusses isolation across tenant context, storage, caches, and background processing.

Use the general multi-tenant SaaS guide for the foundations. This article focuses on partner operators and asynchronous evidence access.

Resolve customer context before accessing data

The browser can request a customer context. The server must verify that the current person may use it.

Load approved memberships and action permissions from trusted records. Do not trust a header, route parameter, or job payload merely because it contains a valid tenant identifier.

Pass the resolved context through the service boundary. Include the actor, customer, action, and correlation identifier where needed.

Scope data queries and object-storage paths to that customer. Include the customer boundary in cache keys that contain customer-specific data.

Analyst session and current customer assignment
                    |
                    v
Case permission and export request
                    |
                    v
Trusted job record with bounded authority
                    |
                    v
Worker rechecks policy and reads scoped evidence
                    |
                    v
Customer-scoped result and authorised retrieval

Avoid copying customer evidence into general queue messages. A job identifier can refer to a protected server-side record.

Define access removal for queued work

A queued export can outlive the session that created it. Decide what happens when an analyst loses access before the worker starts.

For sensitive evidence exports, our proposed default is to recheck current authority before execution and retrieval. Record any approved service-owned exception separately.

Tie the job to its original customer and requested resources. A worker must not accept a later customer change from an untrusted message.

Set a result expiry and a removal process. Restrict who can retrieve the output after completion.

Retries need the same boundaries. Do not let retry logic replace a denied customer context with a platform-wide service account.

This design adds policy lookups and failure handling. Plan for those costs instead of allowing stale authority to keep jobs moving.

Restrict connectors and response actions

Security tools can collect sensitive evidence or trigger changes in customer systems. Read access and response authority deserve separate scopes.

For each connector, record its owner, customer, permitted resources, and rotation process. Use a documented authentication method appropriate to the target service.

Keep collection credentials separate from analyst sign-in. Revoking an analyst session does not necessarily revoke a connector credential.

For response actions, show the exact customer and target before approval. Examples include disabling an account or requesting endpoint isolation.

Record who approved the action and which workload executed it. A dashboard label such as administrator should not silently authorise every connected system.

Our access-token and ID-token guide explains why an identity token is not a general API credential.

Test boundaries across the whole export journey

Use synthetic customer evidence for these proposed acceptance checks. They describe expected behaviour, not results from a completed product assessment.

Test	Expected result
An analyst changes the customer identifier	The server verifies the new assignment
A queue message requests another customer's case	The worker rejects the context mismatch
An analyst loses membership before execution	The job follows the current-authority policy
A completed result is requested by another customer	Retrieval is denied
Two customers use the same local case identifier	Cache and storage keys remain isolated
A connector collects from an unassigned customer	Its credential and resource boundary reject access
A read-only analyst requests a response action	Separate response permission is required

Include counts, previews, error messages, and search suggestions in your review. Each can reveal information even when the main evidence route is protected.

Download the partner-platform review sheet to assign owners across your API, worker, storage, and support teams.

Review your platform identity boundary with NamoID

NamoID Customer Identity provides hosted authentication, OAuth and OpenID Connect, passkeys, and TOTP MFA for your application's users.

Our engineers can help you review analyst sign-in, recovery, and session integration. Your services still own customer isolation and background-job authority.

NamoID is not an endpoint response platform. Customer connector credentials, evidence storage, and response approvals need their own controls.

Message NamoID's engineers in Slack for an early response. Share your stack and a sanitised request-to-worker diagram.

We can help identify the next integration step. Keep customer evidence and live credentials out of the community channel.