Prepare enough penetration-testing accounts to compare every meaningful authorization boundary—not one account per screen and not one generic user for the whole application. Most web or API assessments need at least two peer users for horizontal checks, representative privileged roles for vertical checks, and separate tenants where tenant isolation matters. Add machine identities when APIs, jobs or integrations use them.

The exact count comes from the role-and-tenant matrix. Engineering should model actors, objects and actions, then create the smallest account set that can prove whether each important policy is enforced.

Why one account is insufficient

A single authenticated account shows what that identity can do, but not whether it can act on another user’s object. Without a peer account, testers may use guessed identifiers without a reliable expected-policy comparison. Without a second tenant, cross-tenant access cannot be tested safely and deliberately.

One all-powerful administrator is also insufficient. It proves little about privilege escalation, delegated administration or support access because the expected policy already permits broad actions.

Start with actors, objects and actions

  1. List human roles and machine identities.
  2. List sensitive objects and which identity owns or administers them.
  3. List important actions: view, edit, approve, export, share, delete or transfer.
  4. Record the expected policy for same-user, peer-user, cross-role and cross-tenant combinations.
  5. Select accounts that let the tester exercise each high-risk relationship.

The minimum peer-user pattern

For a standard authenticated role, create User A and User B with separate data. This supports horizontal authorization testing: can A read, change, delete or act on B’s object? Use clearly labeled synthetic records so evidence does not involve real customers.

If ownership changes through sharing, invitation or transfer, create the states needed to test before, during and after that transition. Account count is not useful unless the data relationships match the workflow.

The multi-tenant pattern

  • Tenant Alpha: at least one normal user and any critical privileged role.
  • Tenant Beta: a peer normal user and representative data.
  • Cross-tenant user where legitimate multi-membership exists.
  • Support or platform administrator with documented cross-tenant authority.
  • Delegated administrator where customer-managed permissions differ from platform administration.

This set supports same-role cross-tenant checks, vertical checks within one tenant, membership transitions and support-boundary testing. More accounts may be needed for hierarchical tenants, parent-child organizations or multiple support tiers.

Privileged and administrative roles

Include roles that can change access, export data, impersonate users, manage billing, approve transactions or configure integrations. Do not create every internal job title if several roles share the same effective policy. Conversely, do not collapse roles that differ at a critical control boundary merely to reduce setup work.

  • Customer administrator versus ordinary customer user.
  • Read-only auditor versus operational editor.
  • Support agent versus platform administrator.
  • Approver versus requester in a four-eyes workflow.
  • Integration manager versus integration runtime identity.

Machine identities and API credentials

Prepare service accounts, OAuth clients, API keys or workload tokens when they represent real attack paths. Record their audience, scopes, tenant context, permitted operations, expiry and rotation behaviour. A human user token does not substitute for testing a broadly privileged integration credential.

For APIs with multiple authentication modes, provide representative credentials for each meaningful policy. Testers should not receive production secrets or unnecessary maximum privilege.

Account-recovery and lifecycle identities

Authorization changes when a user is invited, suspended, removed, transferred or recovered. Create test states for workflows that affect trust. Verify whether old sessions, tokens, shares and background jobs retain access after the lifecycle change.

  • Newly invited but not fully onboarded user.
  • Suspended or deactivated user.
  • User removed from a tenant or role.
  • Recovered account after credential or MFA reset.
  • Former owner after object or tenant transfer.

Prepare safe and useful test data

Each account needs distinct synthetic objects that make ownership and tenant context obvious. Include representative files, records, transactions or reports without real personal or financial data. Label data so operations can distinguish test activity and clean it after the engagement.

If a critical workflow requires external messages, payments or partner calls, provide a sandbox or controlled simulation. Do not let a test account trigger real customer communications unintentionally.

Create an account matrix for the tester

  • Account label and role.
  • Tenant or organization membership.
  • Authentication method and MFA process.
  • Owned objects and workflow state.
  • Expected privileges and prohibited actions.
  • Credential delivery and rotation owner.
  • Expiry, cleanup and evidence-handling requirements.

Share credentials through an approved secure channel, not inside the scope document or ordinary email. Validate every account before the testing clock starts.

How many accounts is enough?

Enough means the test can exercise the important policy pairs and transitions. A simple single-tenant application may need two peer users plus one administrator. A SaaS platform may need two tenants, peer users, tenant administrators, a platform support role and one or more machine identities. A complex approval product may need separate requesters, reviewers and final approvers.

Ask the vendor to return a proposed matrix and explain each account. If the number is arbitrary or identical for every application, the authorization scope is probably not architecture-led.

Common preparation mistakes

  • Providing one account and expecting meaningful horizontal authorization coverage.
  • Giving only an administrator because it can access every screen.
  • Creating two users inside the same tenant when cross-tenant isolation is the main risk.
  • Using empty accounts with no owned data or workflow history.
  • Omitting API clients, support roles and machine identities.
  • Sharing real customer accounts or long-lived production secrets.
  • Failing to test credentials before the engagement begins.

The practical decision

Build the smallest test-account set that covers meaningful horizontal, vertical, cross-tenant and machine-identity boundaries. Pair accounts with synthetic objects and documented expected policy. This preparation gives testers reliable authorization evidence without asking engineering to create unnecessary identities.

Ask WIMD to review your role-and-tenant test matrix before account provisioning begins.