Credential handover for pentests
capture, scope, and rotate test credentials on the engagement record
Authenticated pentests live or die on the credentials. Today they arrive on the morning of kickoff in a chat message that nobody can find a week later, get pasted into a tester password manager that the next person on the project cannot read, and survive long after the engagement closes because nobody owned the rotation. Run credential handover as a workflow on the engagement record instead: a defined intake, scoped test accounts, encrypted at rest with AES-256-GCM, role-based access, and a documented rotation at close. The authenticated scan stops being blocked by a missing password and the audit trail captures who held what access and when.
No credit card required. Free plan available forever.
Credential handover decides whether the authenticated pentest happens at all
Authenticated penetration tests stretch beyond the unauthenticated surface and into the application as a logged-in user. That depth depends entirely on the credentials the client hands over. Done well, the handover is captured at intake, scoped per role tier, encrypted at rest, gated by role-based access, and rotated at close. Done badly, credentials arrive in a chat message at 09:30 on the morning of kickoff, get pasted into a personal password manager, and live forever because nobody owned the rotation.
SecPortal models credential handover as a first-class workflow on the engagement record. Cookies, bearer tokens, basic auth pairs, form-login fields, API keys, and mTLS certificates are stored in an encrypted vault with AES-256-GCM at rest, the activity log captures every read, the vault entries drive both authenticated scanning and manual testing, and the rotation at engagement close is captured against the engagement with a named confirmer. The authenticated scan stops being blocked by a missing password and the audit trail captures who held what access and when.
Credential types the vault holds against the engagement
Authenticated tests run against a mix of authentication models. The vault entry on the engagement covers each of them with a consistent shape so the credential lifecycle is one workflow rather than six.
Cookie session
Captured as the session cookie value plus the cookie name and the domain it is bound to. SecPortal injects the cookie into authenticated scans for the agreed role tier and the manual testers reuse the same record so the session under test is consistent across automated and manual coverage.
Bearer token
Stored as the raw token plus the header name (Authorization, X-Auth-Token, or a custom header) and the issuer. Bearer tokens age fast, so the vault entry carries an expiry the engagement lead can read without opening the token. When a token expires mid-test the rotation lands on the same record rather than in a new chat thread.
Basic auth
Stored as username and password against the realm. Basic auth survives in legacy admin panels, internal services, and proxy gateways. The vault entry encrypts both fields at rest and the authenticated scanner injects the Base64 header at run time so the credential never leaves the encrypted boundary.
Form login
Captured as the username, password, the login URL, and the form selectors the scanner needs to walk the login flow. The flow is described in the vault entry, the scanner replays the login on each authenticated scan, and the manual testers reuse the same script so the application is exercised in the same way both ways.
API key
Captured as the key value, the placement (header, query string, or body), and the role tier the key authorises. API keys often carry broader access than cookies, so the scope tier on the vault entry is the gate the engagement lead reads when deciding what the scanner is allowed to exercise.
mTLS client certificate
Stored as the certificate, the private key, and the chain. Mutual TLS is common on financial and OT/ICS estates and the credential set is more sensitive than a password. The vault entry holds the certificate material against the engagement and rotation at close revokes the issued certificate alongside expiring the private key the firm holds.
Where credential handover usually breaks down
Six failure modes recur whenever credential handover is treated as a kickoff-day errand rather than a structured workflow. Each one is invisible at the start of the test and visible at the next audit, the next regression, or the next compliance review.
Credentials arrive on the morning of kickoff in a chat message
The tester wakes up on day one of an authenticated test and the credentials have not arrived. They land in a Slack DM at 09:30, the test starts at 10:00, and a week later the next reviewer cannot find the message. Capturing the handover on the engagement record means the credential request and delivery sit in one place rather than a thread that scrolls away.
A real user gets handed over instead of a test account
The client hands over the CFO is account because it has the right permissions. The test triggers a security alert at 02:00, the on-call security engineer thinks the CFO is compromised, and the scope conversation has to restart against a real incident. Scoped test accounts at intake prevent the entire failure mode.
Credentials live in a tester password manager
The credentials get pasted into a personal password manager so the tester can paste them back later. The next person on the engagement cannot read the manager. The retest six months later starts with a fresh credential ask. The vault on the engagement record is the shared store the team and the client both reference.
No expiry, no rotation at close
The engagement closes, the report ships, and the test account stays alive. Six months later the credential is still in someone is screenshot folder and still authorises the application. Rotation as part of the close-out is the only reliable defence and recording the rotation against the engagement is the only reliable proof.
The same credential gets reused across engagements
A bearer token issued for one test gets reused on the next test because nobody rotated it. The activity log on the application cannot distinguish the two engagements and the audit trail blurs. One credential, one engagement, one rotation at close keeps the trail clean.
Credentials arrive without scope
A handover that says "use this account" with no role tier, no environment, and no expiry leaves every other field as a guess. Scoping the credential at intake means the engagement lead, the tester, and the client agree what the credential authorises before it gets used rather than after the test runs.
Roles in a credential handover workflow
Credential handover is a multi-role workflow with named owners on both sides. Each role has a clear responsibility on the engagement record and the audit trail captures who held which role and when.
Engagement lead
Owns the credential handover protocol on the engagement. Confirms the authentication model and role tiers in the rules of engagement, names the client owner of the handover, and records sign-off on rotation at close. Reads the vault entries via role-based access; never personally holds raw credentials outside the vault.
Client owner of the handover
A named contact on the client side who is responsible for issuing the test accounts, capturing them in the vault, confirming the rotation at close, and confirming the disposal of any test certificates. Captured on the engagement so the firm can demonstrate, at audit time, that the handover had a named counterparty rather than an inbox.
Test author
The tester who runs the authenticated test. Reads the vault entries through role-based access, references them in evidence captures, and flags credential issues (expiry mid-test, rotation needed, role tier insufficient) on the engagement rather than chasing the original handover thread.
Reviewer
The peer reviewer or engagement lead reviewing the deliverable. Confirms the role tiers tested match the credentials issued, that the windows on the vault entries align with the testing window in the report, and that the rotation evidence at close has been captured on the engagement.
Lifecycle of a test credential on the engagement record
| Phase | What happens on the engagement |
|---|---|
| Pre-engagement | The authentication model, the role tiers required, the environment scope, and the testing window are agreed in the rules of engagement. Test accounts are issued by the client owner of the handover; personal accounts are excluded explicitly. The vault entry is created with a label, an expiry, and a requester so the credential arrives against a documented spec. |
| During the engagement | Credentials are read through role-based access, never copied out of the vault. The activity log captures every read. Authenticated scans inject credentials at run time from the vault. Mid-engagement rotations (an expired bearer token, a refreshed cookie, a new role tier added for a depth pass) land on the engagement record and reference the vault entry they replace. |
| At engagement close | Every credential in the vault is rotated, expired, or revoked. The client owner confirms the rotation against the engagement with a timestamp and a named approver. Test accounts are disabled in the application unless they are explicitly retained for a contracted retest. The closing rotation is part of the close-out checklist, not an optional follow-up. |
| Retest and follow-up | Months later, the retest opens against the original engagement. The credential history is attached, the prior role tiers tested are visible, and the next ask references what was issued before. Fresh credentials are issued for the retest under the same protocol; old vault entries are kept read-only as audit history. |
Handover checklist for the engagement lead
Before authenticated testing begins, the engagement lead walks the handover against a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above.
- The authentication model and role tier needed for the test are documented on the engagement before any credential is requested.
- Test accounts are scoped per role tier, tagged as test in the application, and kept out of audit emails to non-engagement contacts.
- Each credential is captured in the encrypted vault on the engagement with a label, an expiry, a requester, and a test plan reference.
- Domain ownership is verified for every host the credentials authorise so authenticated scans only run against assets the firm has been authorised to test.
- Role-based access on the team controls which named members can read each credential, with all reads captured on the activity log.
- Authenticated scans are wired to the vault entries so the credential never appears in a scan profile outside the encrypted boundary.
- Bearer tokens, API keys, and short-lived cookies carry an expiry on the vault entry and rotation drops onto the same record when they cycle.
- Engagement close triggers a rotation step on every credential and the rotation is confirmed on the engagement with a named approver.
- mTLS certificates issued for the engagement are revoked at close alongside expiring the private key the firm holds.
- The credential history stays attached to the engagement record so the report references it and the retest reads the prior context.
How credential handover looks in SecPortal
Credential handover is one workflow stitched into four feature surfaces: the engagement record, the encrypted credential vault, role-based team access, and the authenticated scanner. The same record drives the credential lifecycle and the audit trail.
Capture in the vault
Open the credential vault on the engagement and capture each credential against a label, an expiry, and a requester. Encryption is AES-256-GCM at rest and the credential never leaves the encrypted boundary.
Gate access by role
Use team management to control which named members can read each credential. Reads land on the activity log so credential access is auditable rather than silent.
Verify the host
Pair the credential with domain verification so authenticated scans only run against hosts the firm has demonstrably been authorised to test. The combination prevents credential reuse outside scope.
Wire into authenticated scans
Attach the vault entry to an authenticated scan so the scanner walks the application as the agreed role tier. Cookie injection, bearer headers, basic auth, form login, and mTLS all run from the vault. The storage architecture and access model behind the vault are documented in encrypted credential storage.
Track expiry mid-test
Each entry carries an expiry. When a bearer token cycles or a short-lived cookie refreshes, the rotation lands on the same record so the test does not stall and the replacement keeps the audit trail intact.
Rotate at close
Engagement close triggers a rotation step on every credential. The client owner of the handover confirms the rotation against the engagement with a timestamp and a named approver, and the audit trail closes the loop.
Where credential handover sits across the engagement lifecycle
Credential handover composes with the rest of the engagement lifecycle on the same record so the work that goes in once does not have to be redone at every stage.
Upstream and downstream
Credential handover takes the output of pentest client onboarding and feeds the depth pass run by web application testing and API security testing. The credential history rolls forward into pentest evidence management and into retesting months later. When a tester rotates off mid-engagement, credential handover is one of the artefacts the wider tester rotation and handover workflow transfers cleanly so the access surface does not linger past the rotation date.
Project context
Credential handover is one phase inside pentest project management. The engagement lead schedules the handover before authenticated testing begins, confirms scope and expiry on the vault entries, and tracks rotation at close alongside scope, evidence, and findings on the same record.
Pair the workflow with the long-form guides
The workflow is operational; the surrounding guides explain the trade-offs that show up at handover time. Pair this use case with the pentest credential handover form template for the executable artefact that opens the lifecycle on the engagement record, the writeup on authenticated vs unauthenticated scanning for the depth case authenticated tests rest on, the web application penetration testing checklist for the test plan that the credentials feed, API security testing checklist for the API-side authentication patterns, and the domain verification and responsible scanning guide for the host-authorisation half of the same workflow.
Buyer and operator pairing
A structured credential handover is the workflow pentest firms, security consultants, and internal security teams run when authenticated testing has to clear procurement and audit scrutiny. Framework references that mandate the credential discipline include ISO 27001 for cryptographic controls and segregation of duties, PCI DSS for handling of authentication data, and CREST for documented test account handling on accredited engagements.
What good credential handover feels like
Defensible record
Credentials are encrypted in the vault, scoped per role tier, gated by role-based access, and rotated at close. When an auditor asks how authentication data was handled during the test, the answer is on the engagement rather than in someone is memory.
Clean close-out
Rotation at close is a step on the engagement, not a follow-up nobody owns. The client owner confirms the rotation, test accounts are disabled, and the vault entries become read-only audit history rather than live credentials drifting into next quarter.
Credential handover is the workflow that decides whether the authenticated pentest happens at all. Get it right and the depth pass runs cleanly, the audit trail is defensible, and the rotation at close is a recorded step rather than a forgotten intention. Get it wrong and the test stalls on day one, the credential lingers for months, and the firm cannot answer the audit question that comes up when the next procurement review starts.
Frequently asked questions about credential handover for pentests
What is credential handover for a pentest?
Credential handover is the workflow that captures, scopes, encrypts, and rotates the credentials a tester needs to run an authenticated penetration test. It covers cookie sessions, bearer tokens, basic auth pairs, form-login fields, API keys, and mTLS client certificates. SecPortal models the handover as a workflow on the engagement record so the credentials are stored encrypted at rest with AES-256-GCM, role-based access controls who can read them, and the rotation at engagement close is captured on the same record rather than in a chat thread.
Why should credentials live on the engagement record?
Three reasons. First, the credentials are part of the engagement, so the audit trail (who read them, when, and what scope they authorised) belongs on the same record as the findings and the report. Second, the next reviewer on the engagement (the peer reviewer, the retester six months later) needs the prior credential context to do their work. Third, the rotation at close is only enforceable if the credentials have a single home that the engagement lead can walk through at sign-off.
How are credentials encrypted in SecPortal?
Credentials in the vault are encrypted at rest with AES-256-GCM. The encryption key is held outside the credential record and is never written to logs or surfaced in API responses. Reads through the platform are gated by role-based access, captured on the activity log, and the credential is injected into authenticated scans at run time so it never appears in a scan profile or a configuration file outside the encrypted boundary.
Should we hand over a real user account or a test account?
A scoped test account, every time. Real user accounts mix personal data into the test scope, blur accountability when a security alert fires, and leave a clean-up problem when the engagement closes. A test account, tagged as test in the application, scoped to the role tier needed, and disabled at close, solves all three. The credential type is the same; the account behind it is different.
What credential types should we capture?
Cookie sessions, bearer tokens, basic auth pairs, form-login fields, API keys, and mTLS client certificates. Each carries a different lifecycle: cookies and bearer tokens age fast and need expiry tracking, basic auth and form logins survive longer but need rotation at close, API keys often authorise broader scope than the cookie equivalent and need a clear scope tier on the vault entry, mTLS certificates need explicit revocation on the issuing side at close.
How does credential handover support authenticated scanning?
The vault entry on the engagement is the source of truth for the authenticated scan. SecPortal injects the cookie, header, basic auth pair, form-login flow, or mTLS material at run time so the scanner walks the application as the agreed role tier without the credential leaving the encrypted boundary. The same record drives manual testing too, so the role tiers exercised by the scanner and the testers are consistent and the credential lifecycle is one record rather than two.
When should we rotate the credentials?
Rotate at close, every time, and rotate mid-engagement when a credential expires or when the role tier needed changes. The closing rotation is the only reliable defence against a stale credential lingering after the test, and capturing the rotation against the engagement with a named confirmer is the only reliable proof. Bearer tokens and short-lived cookies often need a mid-engagement rotation that lands on the same record so the test does not stall.
How does this fit with domain verification?
Domain verification confirms the firm is authorised to test the host. Credential handover confirms the firm is authorised to test the host as a specific role tier. SecPortal pairs the two so authenticated scans run only against verified hosts, and the credential vault entry references the verified domain. The combination prevents credential reuse against an asset that was never in scope.
How it works in SecPortal
A streamlined workflow from start to finish.
Define the credential ask in the rules of engagement
Capture the authentication model on the engagement: cookie session, bearer token, basic auth, form login, mTLS client certificate, API key, or a combination. Specify the role tier needed for each (read-only, standard user, admin, billing, support impersonation), the environment scope (production, staging, dedicated test tenant), and the testing window the credential is valid against. The rules of engagement reference the agreed model so credentials arrive against a documented spec rather than against a verbal request.
Use scoped test accounts, never personal accounts
Issue a fresh test account per role tier rather than handing over a real user is credentials. Test accounts are tagged in the application as test, kept out of audit emails, and disposed of at engagement close. Sharing a real user is account leaks personal data into the test scope, blurs accountability when the test triggers a security alert, and leaves a clean-up problem when the engagement ends. Scoped test accounts solve all three.
Capture credentials in the encrypted vault on the engagement
Store every credential against the engagement in SecPortal is encrypted credential vault. Cookies, bearer tokens, basic auth pairs, form-login fields, API keys, and mTLS certificates land in the vault with AES-256-GCM encryption at rest. Each entry carries a label (the role tier and environment), an expiry date, the requester, and the test plan it supports. The vault is the source of truth, not a screenshot in a chat thread.
Restrict access with role-based controls
Team management gates who on the engagement can read each credential. Engagement leads, test authors, and reviewers see what they need; billing roles never see credentials at all. Role-based access enforces the segregation of duties that auditors expect on regulated tests, and the activity log captures every read so a credential is never accessed silently.
Wire the credentials into authenticated scanning
For authenticated DAST, attach the stored credential to the scan profile so the scanner walks the application as the agreed role tier. Cookie injection, bearer header injection, and form-login flows are all driven from the vault entry; the scanner never sees the credential outside the encrypted boundary. The same credential record drives manual testing and automated scanning, so coverage is consistent and the credential lifecycle is one record rather than two.
Confirm domain ownership before any scan runs
Authenticated scans target real production-adjacent assets, so SecPortal will not run an authenticated scan against a host whose ownership has not been verified. Pair the credential vault with the domain verification workflow so each credential is bound to a host the firm has demonstrably been authorised to test. The combination prevents credential reuse against an asset that was never in scope.
Rotate or revoke at engagement close
Closing an engagement triggers a rotation step on every credential in the vault. The client rotates the test account password, revokes the bearer token, expires the API key, and confirms the rotation against the engagement. SecPortal records the rotation timestamp and the named confirmer so the audit trail can show that the credentials issued for the test no longer carry access. Test accounts themselves are disabled at the same time unless the client retains them for a follow-up retest.
Carry the audit trail into the report and the retest
The credential history stays attached to the engagement record. The report references the role tiers tested, the windows the credentials were active, and the rotation evidence at close. When the retest opens months later, the next reviewer reads the prior credential context against the new ask rather than starting the credential conversation from scratch.
Stop running credential handover on chat and a password manager
Capture, scope, encrypt, and rotate test credentials on the engagement record. AES-256-GCM at rest, role-based access, and a clean handover trail. Start free.
No credit card required. Free plan available forever.