Security Test Access Handoff: Scope, Accounts and Revocation
A tester asking for VPN credentials needs a scoped handoff, not a spare login. Gate the authorization, name targets, issue accounts, then revoke.
A tester asks for a gateway address, internal DNS details and VPN credentials, and the request is forwarded to you with the subject line "access needed". The request alone does not tell you whether this is an internal assessment, an authenticated application test, or a public website engagement where someone has misunderstood the scope. Run the handoff as a sequence with a gate at each step, and stop at the first gate that does not open. That turns a vague request into something you can authorize, deliver and later revoke.
Start with the authorization, not the credentials
Before any address leaves your inbox, establish who owns the targets and who is allowed to approve testing on them. Verify the tester through the engagement contact your organization already uses, not through the person who forwarded the email. A customer relationship is not permission to test every system reachable from an account, and a purchase order is not a scope document.
Write the approved objective in one sentence and keep it next to the handoff. "Assess the customer portal's authentication" and "assess the internal network" lead to completely different packages, and the difference has to be settled before provisioning rather than after a finding lands. The sentence also gives you something to point at when the request grows mid-engagement.
If a hosting provider or another third party is in the path, their requirements come before your convenience. Testing someone else's infrastructure without their permission is a separate problem from testing the application that runs on it.
Name the viewpoint and the targets
The viewpoint is the question the assessment is trying to answer, and it determines the access package more than any tool the tester plans to use. A public unauthenticated test needs a URL and a window. An authenticated test needs dedicated accounts for the specific roles in scope, and an internal assessment needs a defined entry point with explicit target ranges.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
Where a tunnel enters is not the same fact as which application sits behind it, and it certainly does not authorize probing the entry point. Say that explicitly in the handoff, because the sentence "you gave me access to that subnet" arrives quickly once a finding is disputed. A written target list is the only thing that settles it afterwards.
Give the TLS hostname alongside the URL. A bare IP address forces the tester to guess the name, and a guessed name produces certificate errors that get reported as findings rather than as a handoff mistake.
Issue dedicated identities with an expiry
Provision accounts that exist only for this engagement; do not lend a staff member's everyday login. Set network reachability and application permissions to the agreed tasks, arrange authentication enrollment through a supported path, and attach an expiry date with a named person responsible for revocation. Deliver the credentials through an agreed secure channel, separately from the scope document that gets forwarded around.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Record who received what, and when. That record is the difference between a controlled handoff and a shared password nobody can trace, and it is the first thing anyone asks for after an incident. Keep it with the scope document rather than in a chat thread, and note the delivery channel alongside the recipient. A timestamped line beats a recollection every time.
The expiry field is a backstop, not the plan. Someone still has to remove the network path and the application role at the end, because an expired login on a still-reachable network is not revoked access.
Prove the handoff works before the window opens
Run the tester's first hop yourself, from a position as close to theirs as you can get. Resolve the name, check the certificate identity, and confirm the path reaches the intended address rather than a neighbouring one.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
If the path cannot reach a target, pause and reconcile the handoff rather than letting the tester discover an alternative route. Improvised reachability is how an assessment quietly expands beyond its scope, and it is almost never documented afterwards.
Send the operational contact, permitted hours, excluded actions and stop conditions with the credentials. A tester who cannot reach anyone at 02:00 will make a judgement call you did not authorize, and that call will be described in the report as if it were in scope.
NIST SP 800-115 frames a technical assessment as planned testing followed by analysis and mitigation, which is the shape this handoff follows. The gates above are editorial design choices for a support engineer, not a checklist quoted from that publication.
Close the engagement by removing access
Revoke in the reverse order of provisioning: application roles, then network access, then the identity itself. Confirm each step instead of assuming the console did what the button promised. Lock the account before you kill its sessions, or the session simply re-authenticates against the old path. Then check the established connections once more before you call it closed.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Settle any retained test data, then track remediation through the reporting process you agreed at the start. The report should state the environment, the access level, the scope and the limitations, because it records findings from one assessment and is not a permanent statement that the site is secure.
Keep the revocation record with the handoff record. When the next engagement opens, you want to know exactly what was removed last time and who signed it off, rather than rebuilding the picture from memory.