Parallel browser logins can silently revoke an authenticated scanner's own sessions and turn privileged tests into false negatives.
Browser A signs in to an admin portal and loads the profile page it expects. Browser B signs in with the same account. Browser A refreshes and lands on the login screen. Both logins succeeded, but the portal allows one active session per account, so the second login revoked the first.
Now suppose an automated scanner takes Browser A's place. It holds one recorded login for a test account and has fifty authenticated pages to examine. If it opens fifty browsers and signs in from each, every login can revoke the one before it. The scanner keeps working after logout. Each privileged endpoint now answers it as if it were public. Nothing raises an error. The assessment silently records every privileged page as safe, and the parallelism that caused the false negatives disappears from the result.
The mistake is not that the scanner ran too many browsers for its own hardware. It ran more browsers than the target was willing to authenticate at once, and browser count is a knob most automation treats as its own to set. Pentest Copilot is an autonomous pentesting system that drives many browsers against one target from a single recorded login, so it has to answer one question before scheduling any of them: how many browsers may this login hold at once?
The portal exposes two properties that are easy to conflate. Session validity asks whether one browser is authenticated right now. Session concurrency asks whether that authentication survives a second tab or a second login. OWASP classifies simultaneous logons as an application policy. An application may permit several sessions, ask the user which one to keep, or end the older session when a new one begins. A successful login does not reveal which of those is in force.
Before concurrency can be measured, the recorded identity has to work at all. Three checks establish that, and each answers a different question.
Every check leans on a verifier, which is the page or endpoint that gets reloaded to ask whether the browser is still logged in.
The second check is a control that has to fail. A public landing page can contain the word Dashboard, and an expired session can render a login screen that looks close enough to the real page to score as a match. When the saved session and the clean browser both satisfy the verifier, the verifier is not measuring authentication at all.
The third check proves less than it appears to. It shows the recorded steps can regenerate access after the saved state expires, which is a claim about one browser at one moment. NIST SP 800-63B frames a session the same way: holding the session secret proves possession for one interaction, and nothing about that possession describes how many interactions the target will tolerate side by side.
Each replay is a new authentication event. Against a single-login application, each one can revoke the session created moments earlier, so a fleet of replaying workers spends its time logging its own members out. Passing all three checks earns the right to run one browser, not many.
Concurrency splits in two because a browser can hold a session in two different ways.
A browser context is one isolated cookie jar and storage area. Pages inside a context share it, and separate contexts share nothing. Playwright draws that boundary explicitly, and it happens to line up with the boundary the application enforces.
A second tab in Browser A reuses Browser A's context, so the application usually sees one session with two pages open and no new login. The shared-tab test opens several pages inside one authenticated context, reloads the verifier in each, and passes only when every page is still authenticated.
Browser B is the harder case, because it starts empty and has to log in for itself. The independent-browser test replays the login in several clean contexts at once, waits, then rechecks the verifier several times. The wait earns its place: an application can accept both logins and revoke one only after a token refresh, and a check run immediately would record a pass that evaporates a second later.
A scheduler cannot act on two test outcomes. It needs one instruction, and that instruction has to be conservative, because the cost of overstating it is the false negative from the opening.
The answer is stored on the browser session as a concurrency mode, and it begins as unvalidated. Only evidence moves it.
| Shared tabs | Independent browsers | Recorded mode |
|---|---|---|
| Pass | Pass | Separate browsers |
| Fail | Pass | Separate browsers |
| Pass | Fail | Shared tabs in one browser |
| Fail | Fail | One serialized tab |
Independent browsers passing settles the question on its own. Each context kept its authentication while the others were logging in, so a failed tab test cannot narrow the result: separate contexts do not share tab state.
When only the tab test passes, one authenticated browser can carry concurrent page work and nothing more. The record also keeps how many tabs stayed authenticated, so a later scheduler opens that many and no more.
When both tests fail, or when the first three checks fail, the mode stays at one serialized tab. Missing proof is not permission.
Return to the admin portal. Its saved state passes, its clean browser fails as required, and its recorded steps regenerate access. Three tabs in Browser A stay authenticated. Two clean browsers then replay the login, and Browser A loses access once the policy settles.
The portal has not produced an invalid session. It has produced a session that is valid, replayable, safe across three tabs, and unsafe for a competing login. The fifty pages from the opening can now run through one browser three at a time, instead of fifty browsers that cancel each other.
Concurrency validation is a point-in-time experiment. A session can pass every test and still expire an hour later, lose access after a password change, or be revoked by a risk engine reacting to a new address. A weak verifier can break the result even earlier: static pages, cached responses, unstable visual hashes, and loose regexes all misclassify validity, and everything downstream inherits the mistake. An identity endpoint with a clean failing control is stronger evidence than a landing page.
Shared tabs give concurrency, not isolation. One tab can log out, rotate a token, rewrite storage, or change account state for every sibling page, so page ownership and destructive-action limits are still required after the tab test passes. Replaying logins is not free. It can trigger MFA prompts, rate limits, lockouts, and security alerts. Dedicated test accounts and bounded replay attempts reduce that cost, and some targets should stay serialized by policy whatever the experiment says.
Login concurrency also differs from request concurrency. An application can keep several sessions alive while still rejecting simultaneous writes or enforcing one-time workflow state, so the recorded mode governs where a browser runs and never overrides endpoint-level race rules. A stored mode is not enforcement either: the scheduler has to read it before it places work, because a measurement nothing consults prevents nothing.
Every authenticated scanner already makes this decision. Most make it by assumption, sizing browser count from the hardware available rather than from the policy the target enforces, and an assumption that happens to be wrong does not announce itself. It returns a clean report on endpoints nobody actually tested. Measure the two policies before dispatch, or run one browser and pay the wall-clock cost of being right.
