Authenticated scanning

Much of an application’s risk lives behind a login. To let Vortex test there, you give it test users — saved sets of credentials that Vortex uses to sign in during a scan. Test users are saved per site and reused across scans, so you configure them once rather than re-entering credentials every time.

Note

Test users are a Vortex feature. Maelstrom load tests don’t use saved test users.

Where to manage test users

Test users live with the scan you’re setting up:

1. Go to Vortex → Run scan and pick the target site (test users are per-site, so the site determines which test users you see).
2. On the Authentication card, choose Manage to open the test-user drawer.
3. From the drawer you can list, add, test, and remove the site’s test users.

Managing test users requires the manage test users permission; see Allow-rules. It isn’t tied to a subscription tier.

Creating a test user

In the drawer, choose to add a test user and provide:

• A name to identify it (unique within the site), and an optional role.
• An authentication type — the options depend on whether the site is a web application or an API.
• The credentials for that type (see below).

Authentication types

The available types depend on the site type.

Web application sites

Type	What you provide
Form	The login URL, the username and password field names and values, and any extra form fields.
JWT	A JWT token (and, optionally, a custom header name and token prefix).
Puppeteer	A Puppeteer browser-automation script (a .js file) and a timeout. Best for complex logins.
AI	The login URL, plain-language sign-in instructions, a username and password, and step/time limits. Vortex performs the login interactively.

API sites

Type	What you provide
Bearer	A bearer token.
Basic	A username and password (HTTP Basic auth).
Headers	One or more custom header name/value pairs.

Both site types also offer None (no authentication).

Note

The AI authentication type is available for web application sites only.

Two-factor authentication (TOTP)

If your login is protected by an authenticator-app second factor (a TOTP 6-digit code, the kind Google Authenticator, Authy, or 1Password generate), Vortex can pass it. On a Form or AI test user, provide the account’s TOTP secret — the same base32 secret (or otpauth:// URI) you’d get from the QR code when enrolling the authenticator. Vortex generates the current code at sign-in time and enters it into the 2FA prompt.

• Supported for the Form and AI authentication types (the interactive logins Vortex drives). It doesn’t apply to token-based types, which don’t have a login step.
• On long scans, Vortex re-generates a fresh code if it needs to sign in again mid-scan.
• The secret is stored the same way as the rest of a test user’s credentials — encrypted at rest — and is never written to logs or shown back to you.

Tip

A TOTP secret is a long-lived shared secret — treat it like a password. Use a dedicated test account and rotate it periodically.

Testing credentials

After you create a test user, use Test credentials to confirm they work. The test runs in the background and the test user shows a status:

Status	Meaning
Untested	You haven’t tested the credentials yet.
Testing	A test is currently running.
Valid	The credentials authenticated successfully.
Invalid	The test ran but sign-in failed (for example, a wrong password or an unreachable login).
Error	Something went wrong while testing.

Testing is optional but strongly recommended.

Caution

An untested or invalid test user doesn’t block you from launching a scan — but the scan will fail to sign in at runtime, so its authenticated coverage will be incomplete. Test credentials before you rely on them.

Using a test user in a scan

On the Authentication card of the Run scan page, pick a saved test user from the dropdown. Vortex signs in with it and exercises the authenticated surfaces of your application. Selecting a saved test user overrides any manual authentication fields on that card.

This works for every Vortex scan type — see Analog, AI pen-test, and API scans.

Good practice and limits

• Use dedicated test accounts. Prefer purpose-made test credentials over real production accounts, and rotate them periodically.
• Credentials are stored securely. Test-user credentials are encrypted at rest.
• Editing isn’t available yet. To change a test user’s credentials, delete it and create a new one.
• Test users are per-site. Two sites need their own test users, even if the username and password are the same.

Next steps

• Run an Analog scan or an AI pen-test.
• Reading a Vortex report.