Validate identity and tenant coverage with a traceable authorization matrix, not a count of test accounts. The matrix should connect actors, target objects, actions, tenant relationships and lifecycle states to test evidence. It must show representative same-role peers, vertical role pairs, cross-tenant identities and administrative exceptions, plus any combinations sampled or omitted.
Exhaustively testing every permutation may be impractical. The provider should explain equivalence groups, risk-based sampling and the shared controls that justify sampling. Silent omission is the failure to avoid.
Model authorization as relationships
Role names describe an actor but do not define the security decision. Authorization depends on the actor’s role, target ownership, tenant, object state, delegated authority, action and sometimes time or workflow history.
- Actor identity and active role.
- Actor tenant and membership state.
- Target owner, target tenant and parent-child relationship.
- Requested action and data sensitivity.
- Object or workflow state.
- Support, delegation, impersonation or emergency context.
Build the matrix around these relationships so that two users with the same label can still be tested as peers with different ownership and tenant context.
Include four essential identity comparisons
Unauthenticated to authenticated
Verify that protected reads and actions are unavailable without valid identity, including direct API calls and cached artefacts.
Vertical role pairs
Test lower-to-higher access and higher-role boundaries. Administrators may have broad rights within one tenant but no right to another tenant or platform-level function.
Same-role peers
Create two users with the same role and separate owned objects. Horizontal authorization flaws are missed when every account tests only its own data.
Cross-tenant pairs
Use controlled identities in distinct tenants, including any shared user, parent organization or support relationship. Test direct reads, writes, searches, exports and indirect effects.
Cover lifecycle and state changes
- Invited but not activated.
- Recently promoted, demoted or transferred.
- Suspended, revoked or deleted while a session remains active.
- Object transferred between owners or tenants.
- Delegation expired or approval state changed.
- Tenant migration, merge or offboarding in progress.
Authorization often fails when cached context outlives a change. Include session refresh, background processing and long-running exports where they use identity or tenant state.
Map actions to protected resources
Group operations by security meaning rather than testing every endpoint equally. For each resource family, include create, list, search, read, update, delete, export, share, approve and administrative actions where applicable.
- Identify the policy or service expected to enforce the action.
- Select representative routes and clients using that control.
- Test authorized positive cases first to establish valid state.
- Substitute peer, role and tenant identities in negative cases.
- Try alternate identifiers, bulk operations and indirect workflows.
- Record results and expand when a shared-control assumption fails.
Test tenant isolation outside request handlers
- Search indexes and autocomplete.
- Exports, reports and generated files.
- Object storage and signed URLs.
- Caches and content delivery layers.
- Queues, notifications and background jobs.
- Logs, analytics and support tooling.
A clean primary API does not prove tenant isolation in asynchronous or derived data paths. Include these components in the system model and coverage record.
Define equivalence and sampling rules
Sampling is defensible when routes use the same verified policy, data-access pattern and identity context. Select representatives across high-impact actions and confirm that legacy, bulk or alternate-client paths do not bypass the shared enforcement.
Do not treat similar names or UI screens as proof of equivalent controls. Ask the application team and tester to state the technical basis for each group.
Require evidence behind checked matrix cells
- Account and role identifiers using safe aliases.
- Source and target tenant relationship.
- Resource ownership and state.
- Request, action or workflow tested.
- Expected and observed outcome.
- Evidence reference, limitation or blocker.
The final report can summarize the matrix, while detailed tester records remain protected. A checked box without an evidence reference or sampling explanation is not reliable coverage.
Reconcile scope changes during testing
New routes, roles and tenant behaviours often appear after access begins. Use coverage checkpoints to add, sample or explicitly defer them. Record account failures and unavailable data immediately so engineering can restore testability before the engagement ends.
Interpret a clean matrix carefully
A matrix shows that representative decisions were exercised under stated conditions. It does not prove every future release or every object is secure. Review shared-control assumptions, environment differences and blocked combinations alongside the result.
Use the access-control and identity-oriented techniques in the OWASP Web Security Testing Guide as inputs, then tailor the matrix to your product’s roles, tenants, lifecycle states and business actions.
Turn coverage into regression protection
Preserve important identity pairs and negative cases as automated or manual regression tests. Link recurring failures to shared authorization controls. After role, tenant or identity architecture changes, update the matrix and trigger focused independent testing.
The practical decision
Validate coverage by asking for an authorization matrix that represents relationships, not account counts. Require same-role, vertical and cross-tenant comparisons, lifecycle states, representative actions, sampling rationale and evidence. The matrix should make skipped combinations visible and guide both retesting and future regression coverage.
Ask WIMD for identity- and tenant-led penetration testing with a traceable authorization matrix and explicit coverage statement.