Scanner accounts

Dedicated user accounts for automated security scanners (Intruder.io, Burp, ZAP). Designed to bypass MFA at login and receive long-lived JWTs, while being explicitly blocked from anything destructive.

The problem we solved

Automated security scanners need to log in to test post-authentication pages. They can't generate TOTP codes, so MFA-required login is a wall. The temptation is to disable MFA on a regular user account — but that's a real security regression: that account still has full user permissions, and "MFA off" is exactly how rogue accounts get exploited.

Scanner accounts solve this with a dedicated identity type that's clearly tagged, narrowly scoped, and easy to disable.

What a scanner account can do

  • Log in without MFA (bypass at the auth layer)
  • Receive a short-lived 24-hour JWT (deliberately shorter than the 7-day standard — re-authenticate each scan run)
  • Browse the app as a basic user
  • Hit any read endpoint that a basic user can

What a scanner account cannot do

  • Access vault routes. All 32 password vault endpoints explicitly check for the scanner flag and refuse with SCANNER_DENIED.
  • Hold any admin role. When enabling scanner mode, the system refuses if the user has Principal, IT Admin, or Enterprise Admin in any user_org_roles row.
  • Be a platform admin. The flag refuses to apply to platform admins.
  • Bypass the audit log. Every scanner action is tagged scanner: true in the audit log so it's distinguishable from real user activity.
✝️
Defense in depth
Even if the scanner credentials are compromised, the blast radius is small. No vault access. No admin actions. No high-privilege endpoints. The 24-hour token can be revoked immediately by resetting the scanner account's password; toggling the scanner flag off blocks the next login (see FAQ).

Enabling scanner mode

  1. 1
    Create a dedicated user account
    Don't reuse a real user. Create something like scanner@thoushaltnotclick.com with no org roles. The account exists solely for scanning.
  2. 2
    Set a strong password
    Long, random, stored only in the security team's secure password manager — not in TSNC's vault (since vault is blocked for scanners anyway).
  3. 3
    Platform → Scanner Accounts → Enable
    Search for the user's email, fill out the optional Notes field (e.g., "Intruder.io continuous scanning"). The system refuses if the user has admin roles.
  4. 4
    Capture the 24-hour JWT
    Log in to TSNC as the scanner via curl or a browser. The login response includes "scanner": true and a 24-hour JWT. Save the token (and refresh it each run — it expires in 24 hours).
  5. 5
    Configure the scanner
    In Intruder/Burp/ZAP, configure header-based authentication: Authorization: Bearer <token>. Run the scan.

Disabling scanner mode

  1. 1
    Platform → Scanner Accounts
    Find the account and click Disable.
  2. 2
    Revoking a scanner token
    A scanner token expires on its own within 24 hours. To kill an outstanding token immediately, reset the scanner account's password — that stamps a revocation timestamp (tokens_valid_after) the API enforces on the token's very next request.
  3. 3
    Confirm the audit log entry
    The disable action appears in your platform audit log so future you can verify what happened.

Configuring Intruder.io

For the most common scanner we work with, here's the canonical config:

  • Entrypoint URL: https://thoushaltnotclick.com/dashboard
  • Logout URL: Leave blank (TSNC has no server-side logout)
  • Logged-in pattern: Log Out (text in sidebar)
  • Auth method: Custom Headers
  • Header: Authorization: Bearer <24-hour-jwt> (configure a login/session-refresh macro so each run re-authenticates)
⚠️
Don't include destructive endpoints in scans
Configure your scanner to exclude /api/auth/login from active fuzzing — repeated bad credentials will lock the scanner account out via TSNC's persistent login-attempt tracker. Also exclude /api/auth/forgot-password (sends real emails) and /api/billing/* (real payment events).

FAQ

Why 24 hours, not the 7-day standard?+
Scanner tokens bypass MFA, so they're deliberately short-lived — shorter than an ordinary 7-day session — to bound the blast radius of a leaked credential. Scanners (Intruder/Burp/ZAP) support a login/session-refresh macro, so schedule scans to re-authenticate each run rather than relying on a long-lived token. The flag itself can be toggled off any time — disabling and rotating the user's password is the immediate revoke path.
Can I have multiple scanner accounts?+
Yes. We use one per scanner tool — separate accounts for Intruder, Burp, ZAP — so we can identify which scanner triggered which event. Audit cleanliness over marginal cost.
Can a scanner account also be used by a real human?+
Don't. The whole point is that scanner accounts have no human attached. If a human logs in to a scanner account, every action they take is tagged as scanner activity in the audit log, which makes future incident response much harder. Use a regular account for human activity.
Is there a way to fully revoke a JWT immediately?+
Yes. Resetting the scanner account's password stamps a per-user revocation timestamp (tokens_valid_after) that the global auth check enforces on the account's next request — every outstanding scanner token stops working immediately. You do NOT need to rotate JWT_SECRET (that would invalidate every token platform-wide). A scanner token also expires on its own within 24 hours regardless.
← Previous
Impersonation safeguards