Why the test needs more than one account
Broken access control is the first category on the OWASP Top 10:2025 list, and it is structurally invisible to single-account testing. A scanner logged in as one user sees a working application; it has nothing to compare against.
Give a tester an admin, a regular user and a second tenant and the questions become concrete: can the regular user call the admin endpoint directly, can tenant one load tenant two's object by changing an identifier, does the server re-check the role or does it trust what the front end sent.
What the test covers
The surface is the whole authenticated application, not just the login page. Scope is written down first, including which environments may be touched and which data may be created.
- Authentication: credential handling, password reset, multi-factor bypass paths, session fixation and invalidation
- Authorization: role boundaries, object-level access control, tenant isolation, direct endpoint access
- Input handling: injection into queries, templates, commands and rendered output
- Business logic: workflows that can be re-ordered, replayed, skipped or run with values the UI would not allow
- Configuration: headers, cookie attributes, exposed debug surfaces, verbose errors
- Dependencies: known-vulnerable components reachable from the application
Staging or production
Testing a staging environment is safer and tells you less, because staging is rarely configured like production. Testing production is accurate and needs tighter rules of engagement.
Either is workable. What is not workable is testing staging and reporting it as production assurance, so the report states which environment was tested and names the configuration differences you told us about.
What arrives in the report
Each finding carries the request that produced it, the account it was sent from, what it returned, and the fix. That is the level of detail a developer needs to reproduce an issue without a meeting.