A dynamic scanner that cannot sign in only tests your login page and marketing pages. Before buying DAST, check how it handles forms, tokens, multi-step login, session expiry and multiple roles. Test it against your real authentication in a pilot, because this is where most scans quietly fail.
Why it decides the value
Most of what matters in an application sits behind authentication: account pages, APIs, admin screens. The OWASP DevSecOps Guideline lists authentication issues among the flaws DAST can detect and notes that some tools are built to handle complex login scenarios, including manually recorded steps, and APIs and single page apps. Handling login well is a differentiator, not a given.
Checklist: can it sign in?
- Standard username and password forms.
- Multi-step flows, such as email first, password second.
- Single sign-on redirects through an identity provider. Ask how test users are set up.
- Token based APIs, where a header or bearer token must be supplied and refreshed.
- Single page applications that render forms with scripts.
- Recorded login sequences for the awkward cases.
Ask for a trial against your staging login, not a demo site.
Checklist: can it stay signed in?
Sessions expire. A scan that logs in once and then wanders into a logged-out state will report nothing useful and may look clean.
- Does the scanner detect it has been logged out and sign in again?
- Does it avoid hitting the logout link?
- Does it handle anti-forgery tokens that change on every request?
- How does it behave when the app rate limits login attempts?
Checklist: can it test multiple roles?
Many flaws appear only when a lower privilege user reaches a higher privilege function. Check whether you can configure several test users, such as ordinary user, manager and admin, and compare what each can reach.
Be careful with expectations. Automated scanning documentation notes logical flaws such as broken access control are not detected automatically, so role testing by a scanner is limited. Plan manual checks for authorization.
Checklist: is it safe?
Use dedicated test accounts and a staging environment. Authenticated active scans can submit forms and change data. Exclude destructive actions like deleting accounts or sending payments.
What to measure in the pilot
- How many pages and endpoints were reached while authenticated, compared with a quick manual walk.
- Whether login stayed valid for the whole scan.
- Time spent on setup.
- Whether results differed between roles.
If setup took days of vendor help, expect that cost every time your login changes.
Quick check
How do I know the scan stayed logged in?
Compare the list of authenticated pages reached against a manual walk, and check the scan log for session loss events.
Should I give the scanner an admin account?
Only a dedicated test admin in staging, since scans can change data. Never use real accounts.
Sources
Last reviewed: 19 October 2026.
