Access Provisioning & Credential Handling
What the client provides for each access level, how it is shared safely, and what Verfend does with it. Completed after the Authorisation to Test (Document 04) is signed and before the testing window opens.
1. What the client provides, by access level
1.1 External (black-box): nothing beyond the signed Authorisation to Test (Document 04). Verfend works from the public internet only, from the tester source IPs listed there.
1.2 Grey-box: dedicated test accounts (section 2), WAF or rate-limit allowances for the tester IPs (section 4) and, where the application is not public, VPN access.
1.3 White-box: everything in 1.2, plus read-only source access (section 5) and a staging environment as close to production as practical (section 6).
2. Test accounts
2.1 Accounts are dedicated to the engagement and named vf-test-* (for example vf-test-admin), so their activity is easy to find in logs and to remove afterwards.
2.2 One account per user role in scope, each with the least privilege that role normally has. Elevated roles are provided only where the Authorisation to Test covers them.
2.3 Accounts use non-production or synthetic data wherever possible; where production data cannot be avoided, the client says so in advance so evidence can be redacted.
2.4 Accounts are created before the window opens and revoked by the client within 24 hours after the Testing Completed Notice (Document 06).
2.5 Multi-factor authentication: ☐ not enforced for vf-test-* accounts ☐ MFA device enrolled by Verfend ☐ backup codes shared through the secure channel.
3. Secure channel for sharing credentials
3.1 Credentials are shared only through the channel ticked below — never in plain email, chat messages, tickets or screenshots.
- ☐ Password-manager share (tool)
- ☐ PGP- or age-encrypted email (Verfend public key fingerprint: fingerprint)
- ☐ Agreed vault or secrets manager: tool
3.2 Shared links expire within hours hours.
4. Network access, WAF and rate limits
4.1 VPN / IP whitelisting: if the assets are not publicly reachable, the client provides VPN access or whitelists the tester source IPs from the Authorisation to Test.
4.2 WAF, CDN and bot protection: the client either whitelists the tester IPs or agrees that testing runs through the protection as a real attacker would; the choice is recorded here: choice. Tester IPs blocked mid-window are a common cause of incomplete coverage.
4.3 Rate limits: allowances for the tester IPs, or the limits Verfend must respect: limits.
5. Source access (white-box)
5.1 Read-only access to a repository scoped to the assets in scope, through a time-limited token or deploy key that expires at the end of the window.
5.2 Verfend does not fork, mirror or push to the repository; local copies are deleted after the final report, keeping only the redacted excerpts needed as evidence, which are retained for 90 days after report delivery and then deleted.
6. Staging parity
6.1 Intrusive checks run against staging where one exists. The client lists known differences from production (versions, feature flags, data, integrations) so the report can state what was and was not covered: known differences.
7. Logging
7.1 The client may log and monitor all tester activity; the vf-test-* naming and fixed source IPs exist to make this straightforward.
7.2 Verfend keeps its own timestamped activity log and shares it on request, for example to reconcile an alert.
8. Handover checklist
| ☐ | Item | Owner | Done on |
|---|---|---|---|
| ☐ | Authorisation to Test signed by both parties | Both | date |
| ☐ | Tester source IPs received and whitelisted where applicable | Client | date |
| ☐ | vf-test-* accounts created, one per role, least privilege | Client | date |
| ☐ | Credentials shared through the agreed secure channel | Client | date |
| ☐ | Login to each account verified from a tester IP | Verfend | date |
| ☐ | VPN access working (if applicable) | Both | date |
| ☐ | WAF / rate-limit decision recorded (4.2, 4.3) | Client | date |
| ☐ | Source token issued, read-only, expiry set (white-box) | Client | date |
| ☐ | Staging differences documented (white-box) | Client | date |
| ☐ | Emergency contacts confirmed reachable | Both | date |
| ☐ | Accounts, tokens and VPN access revoked after the window | Client | date |
| ☐ | Verfend confirms credentials deleted | Verfend | date |
9. What Verfend does with credentials
9.1 Stored only in an encrypted password manager or vault on devices with full-disk encryption; never in notes, scripts, tickets or screenshots.
9.2 Used only for this engagement, only during the window, and never reused for any other purpose or client.
9.3 Deleted after the window closes; the client is told in writing when this has been done (in the Testing Completed Notice).
9.4 If Verfend suspects a credential has been exposed, it tells the client the same day so it can be rotated.
9.5 Evidence gathered with this access is limited to the minimal proof of each finding, redacted where it contains personal data, stored encrypted and retained for 90 days after report delivery, then deleted; no personal data is kept beyond that proof (Service Agreement, Document 03, §6).
10. Confirmation
Access handover confirmed — Client technical contact: ______________ Date: ________
For Verfend: ______________ Date: ________
Verfend · Independent Security Operations · email · website · Document 05 v1.0 · date