Third-party penetration testing: grant access, test roles, and prove closure

Third-party penetration testing often needs more than an IP allowlist. Testers may need a normal user, a privileged test role, a cloud delegation, repository read access, VPN connectivity, API credentials, and a protected place for evidence. The buyer’s real problem is to let the assessment reach the intended boundary without turning a short engagement into durable vendor access.

The useful control object is an access graph, not a list of accounts. A person may enter through an external directory identity, assume a role, obtain a session, use a deploy key, download a repository, create test data, and upload evidence to a portal. Deleting the first account does not necessarily invalidate the other nodes. Closure is proven only when every path is either revoked, expired under an accepted rule, or retained under a named business and security owner.

This guide focuses on access onboarding and technical closure. Broader supplier selection belongs in the evidence-led vendor comparison, while legal scope, authorization, and acceptance belong in the contract and scope guide.

Start with an access graph, not “create a pentest user”

For each testing path, record six connected objects: the human operator, the login identity, any assumed or application identity, the credential or session, the resource grant, and the artifacts the path can create or copy. Add the customer owner and a planned removal action to every object. This makes hidden persistence visible.

Consider one common chain: named tester → guest identity → VPN session → cloud role → object-storage read permission → downloaded evidence. Disabling the guest can stop a future login, yet an existing application session may follow a different policy. Revoking an old cloud role session may still allow a new session if the trust path remains open. Removing repository collaboration does not erase a local clone. An evidence export may be intentionally retained after all interactive access ends.

The graph should therefore distinguish entry, authority, runtime, and residue. Entry is how the tester authenticates. Authority is the role, group, consent, resource policy, repository permission, or delegated application right that decides what can be done. Runtime is the issued token, cookie, VPN lease, SSH session, or assumed-role credential. Residue is the copied code, screenshots, logs, test accounts, uploaded tools, temporary records, and final report.

Do not merge several testers into one shared administrator account. Individual identities make access review, attribution, emergency suspension, and negative testing much more reliable. A shared service identity may still be justified for automation, but it needs a separate owner, credential, action set, log trail, and shutdown step.

Design just-enough access around test claims

The access request should be derived from test claims, not from a job title. “Test authorization boundaries for tenant administrators” is actionable. “Give the pentest team admin access” is not. For each claim, identify the subject role, target resource, allowed actions, prohibited side effects, environment, time window, and evidence needed to accept the result.

Use at least three identity classes when the product has them:

• ordinary operating identities represent real user personas and should have only their intended product permissions;
• privileged test identities exercise administrative or support workflows but should be isolated from unrelated production administration;
• testing infrastructure identities run scanners, collectors, or cloud tooling and should not inherit a human administrator’s broad access.

Keep cloud delegation under customer control. AWS roles provide temporary cross-account access: trust identifies the vendor, permissions constrain resources and actions. A vendor-assigned, customer-specific ExternalId binds requests in a multi-customer service; it is not a secret. For the engagement, separately record session limits, applicable source restrictions, the owner of each grant, and the action that stops new role assumptions.

Time limits are valuable, but “expires Friday” is not a complete closure plan. Some sessions continue after the identity that created them changes; some credentials have no native expiry; and some application sessions are controlled by the application rather than the identity provider. Put both a planned expiry and an executable early-revocation path in the access record.

Test intended roles without quietly changing the scope

A penetration test needs positive and negative evidence. First establish a canary that proves the correct persona can reach the in-scope function. Then use a lower-privileged identity to attempt the same business action and verify denial at the authoritative layer. Finally, inspect the downstream state to show that denial produced no side effect. A user-facing error alone is weak evidence if a queued job, object, or transaction was still created.

Keep testing identities separate from access-administration identities. The customer’s access owner creates or approves grants; the tester uses them; a customer observer can validate logs and side effects. This separation avoids a circular result in which the same vendor account both changes the boundary and declares it secure.

When a missing permission blocks an agreed test, treat the change as a scope event. Record the test claim, requested grant delta, approver, activation time, and removal step. Do not silently promote the ordinary persona or reuse an unrelated production administrator. If a destructive action is not authorized, use a reversible canary, a representative test object, or evidence from a non-production environment and state the limitation in the report.

The pentest scope planner can define systems and constraints, but the access matrix must go one level deeper: which exact identity reaches which exact object through which authority path.

Build an evidence matrix before testing starts

The matrix below turns each grant into a small acceptance test. The owner should fill in concrete identifiers rather than generic labels.

The negative case must match the path being closed. Testing only the web login says nothing about an API token. Testing only a human account says nothing about a deploy key. Testing a role name says little if a resource policy independently grants the same principal. Record the observed component, timestamp, request identity, target, decision, and downstream state.

Close authority in a controlled order

Closure has two jobs: stop future authority and account for what remains. Perform it while the customer can still contact the testers and while logs are still easy to correlate.

1. Freezestop new testing and record the final approved access graph and active work
2. Revokedisable new grants, revoke issued sessions and remove independent credentials
3. Verifyprove the former vendor path is denied while an untouched customer control still works
4. Reconcileinventory artifacts, exceptions, owners, retention dates and final evidence

Start by freezing new activity and collecting a last-used view. Inventory active jobs, callbacks, tunnels, and queued operations; drain or stop them under the approved plan and verify their final state. Revoking the credential that submitted a job does not automatically cancel work already queued or running. Then close the ability to mint new authority: remove trust, assignments, group membership, application consent, collaborator access, and approved network paths as applicable. Next address already issued authority: role sessions, refresh tokens, application cookies, VPN sessions, personal or fine-grained tokens, SSH keys, deploy keys, certificates, and automation secrets.

Order matters. An AWS IAM role-session revocation can deny sessions issued before a cutoff while allowing a newly assumed session afterward, and applying it to a shared role can interrupt other users of that role. Roles generated from IAM Identity Center permission sets have a distinct revocation path. Deleting a user first may also remove the easiest console path for revoking that user’s active sessions. The runbook should identify the actual identity path, state the platform-specific sequence, and keep a customer break-glass owner available until verification passes.

Effective revocation is an observed result, not the timestamp of an administrative click. Re-run the formerly allowed vendor canary through each credential path and require denial with no side effect. In parallel, an untouched customer control should still succeed, proving that the target remains available and the denial is specific to the removed authority. A case that was already denied before closure proves neither revocation nor availability. Record the last successful vendor attempt and first confirmed denial, but do not turn that interval into a universal platform promise. If a session is intentionally allowed to expire, name its maximum accepted lifetime and the compensating restriction that prevents new issuance.

Treat credentials, sessions, delegations, and artifacts separately

Account deletion is attractive because it creates a simple screenshot. It is insufficient as a closeout model.

Repository access illustrates the problem. Removing an outside collaborator can remove hosted access and associated private forks, yet the former collaborator may retain local clones. A GitHub deploy key is a repository-scoped credential that can exist independently of the human who created it and has no expiry. Closeout must inventory the repository’s collaborators, applications, tokens where visible, deploy keys, webhooks, automation secrets, and vendor-held copies. A declaration to delete a clone is a governance control; a failed authenticated fetch is technical proof that hosted access ended. They answer different questions.

Identity platforms have similar layers. Blocking sign-in, revoking refresh tokens, invalidating browser cookies, removing application permissions, and ending an application’s own session are distinct actions. External guests may authenticate in a home tenant, so a resource tenant’s generic user-session operation may not revoke their home-tenant session. The relying application must enforce the changed resource authorization even if the upstream sign-in remains valid.

Artifacts need their own ledger: location, classification, encryption owner, permitted recipients, retention basis, deletion date, and deletion evidence. Preserve the evidence required for the report and possible remediation, while removing test accounts, temporary files, tools, callback endpoints, seeded data, and unintended copies. Do not put credentials, raw secrets, or session tokens into ordinary screenshots or general-purpose logs.

Worked closeout: a hypothetical SaaS assessment

Suppose a SaaS company authorizes an independent team to test tenant isolation. Two named testers receive guest identities and VPN access. The customer creates three ordinary tenant personas, one restricted support role, a read-only cloud log role, and read access to two repositories. A separate vendor automation identity uses a repository deploy key and uploads scanner output to an evidence workspace.

During testing, the team discovers that the support role needs one additional diagnostic action to validate an agreed claim. The customer records the delta, grants only that action, and adds a removal item. The tester proves the allowed diagnostic call works, then shows the same identity cannot alter tenant configuration. A customer observer checks that the denied attempt produced no queued change.

At closeout, the customer first freezes testing and disables new VPN and guest assignments. It removes the cloud role’s trust relationship, revokes older role sessions, and verifies both an existing session and a fresh assumption fail. It removes repository collaborators, deletes the separate deploy key used by automation, rotates the evidence-upload secret, and checks that neither the human nor automation path can fetch repository data. For product test users, the customer first blocks new sign-in and token issuance, then invalidates active sessions and confirms denial on reuse. Uploading evidence with the old credential also fails, while an unchanged customer account retains access.

The team returns an artifact ledger. The final report and selected evidence remain in the customer-controlled workspace under an agreed retention rule. Local clones, temporary scanner output, and seeded records are declared deleted; customer-side logs show removal actions and post-closure denials. One encrypted evidence archive retained by the assessor for a defined dispute window is listed as an exception with owner and deletion date. The result is not “vendor account deleted.” It is a reconciled graph with a proof or named exception for every edge.

What the buyer should accept at handoff

A defensible handoff contains the final access graph, grant changes, test-case matrix, timestamped removal actions, post-revocation results, artifact ledger, and exceptions. It should identify who verified each result and which platform or application made the decision. A denial without a prior positive canary may mean the path never worked; a clean identity list without session tests may miss live authority; a deletion statement without an artifact inventory leaves data handling unresolved.

Independent penetration testing is useful when the buyer needs adversarial validation of real authorization boundaries and evidence that can support remediation. It is less useful when the organization cannot yet provide stable test identities, observe side effects, or authorize safe canaries; an access-design review may be the better first step. Pentest.red can structure role-based test cases, evidence handling, and technical closeout when those controls are part of the agreed engagement. The expected findings format can be aligned in advance with the sample pentest report so access evidence remains actionable rather than becoming a pile of screenshots.