What are the most common authenticated scan failure modes in practice?

Six classes account for most failures. Credentials issued to the scanner do not have the role the scope assumed (a viewer account where an admin scan was scoped). The login form changed and the recorded login script no longer matches the page. The session cookie expires faster than the scanner refreshes it. CSRF tokens rotate per request and the scanner does not extract the new token from each response. MFA was added to the test account and the scanner has no way to satisfy the second factor. SSO redirects the scanner through an identity provider that requires interactive consent the scanner cannot give. Each one looks like a generic failure in scanner logs and needs a different fix.

How should test accounts be provisioned for authenticated scanning?

Authenticated scanning needs accounts that match the scope, not the convenience. If the scope says administrator surface, the scanner needs an administrator account. If the scope says role-aware authorisation testing, the scanner needs at least two accounts at distinct roles to compare what each can see. Accounts should be dedicated to scanning rather than shared with humans, so password rotation and MFA enrolment can be controlled. Where MFA is mandatory in the production environment, a non-production environment with MFA disabled on test accounts (or with a TOTP secret the scanner holds) is usually the only practical path. The credential issuance event itself should be recorded against the engagement so the scope, the role, and the lifecycle of the test account are auditable later.

Why do CSRF tokens break authenticated scans, and how do you fix it?

Many frameworks issue a fresh CSRF token on every form render and reject any non-GET request that does not echo the matching token. A scanner that records a login flow once and replays it later sends the original token and gets rejected. The fix is configuring the scanner to extract the token from each response (usually a hidden form field, sometimes a cookie, sometimes a meta tag) and inject the current value into the next request. Scanners that support recorded macros, response token extraction, and per-request token replay handle this cleanly. Scanners that only replay static requests will fail silently against any framework with a serious CSRF posture.

How do you handle MFA on test accounts without disabling it everywhere?

Three patterns work. The scanner holds the TOTP shared secret and computes the second factor on each login attempt; this is the cleanest approach where the scanner supports it. The scanner authenticates once interactively, captures the resulting session cookie, and then the scan runs against that pinned session for as long as the cookie is valid; this trades freshness for simplicity but requires the scanner to refresh the session before it expires. The third pattern is a non-production environment where MFA is disabled on test accounts only, with the credential record naming why the divergence from production is acceptable. Disabling MFA in production to make scanning easier is the wrong direction; the scanner has to fit the production posture, not the other way around.

What is session pinning and why does it matter for authenticated DAST?

Session pinning is the practice of capturing a valid session cookie outside the scanner (a human logs in, copies the cookie) and configuring the scanner to use that cookie on every request. It is the workaround for login flows the scanner cannot automate (heavy JavaScript, MFA, federated SSO with consent screens). The trade-off is that the pinned session expires; if the scan runs longer than the session lifetime, the back half of the scan runs unauthenticated and the report misses everything past the expiry boundary. The defensible pattern is short scans, frequent re-pinning, and an explicit record on the scan that names the session lifetime so the report can defend the depth.

How do you tell SSO is breaking the scan as opposed to bad credentials?

Watch the redirect chain. A scanner that follows two or three redirects ending at the application home with a session cookie set has authenticated cleanly. A scanner that ends at an identity provider page asking for consent, or that loops through redirects without ever landing on the application, is being asked to do federated authentication it cannot handle. Look at the User-Agent: many identity providers serve different flows to scanners and to browsers. Look at the cookie set: SSO usually sets multiple cookies (the IdP session, the application session, sometimes a cross-domain anti-forgery cookie), and a scan that ended with only a partial cookie set is going to fail on the next request. The fix is usually pre-authenticating outside the scanner and pinning the resulting session, or running the scan against an identity provider profile that accepts non-interactive automation.

How does authentication failure get recorded so the report does not overstate coverage?

The defensible record names four things on every authenticated scan: the scope of the authenticated surface (which routes, which roles), the authentication mechanism the scanner used (form login, token, cookie pinning, SSO), the success signal the scanner relied on (a route count, a specific response shape, a known authenticated marker), and the authentication state at the end of the scan (still authenticated, expired mid-scan, never authenticated). When any of those four are missing or wrong, the scan output is informational rather than authoritative, and the report has to say so. Scans that shipped as authenticated when they were not are the most common reason a finding shows up in production that a clean report should have caught.

← Back to Scanner Information

Scanner guide13 min read

Authenticated Scanner Failure Modes: Debug Login and Session Errors

Most authenticated scans that disappoint did not actually authenticate. The credentials were issued, the login flow was recorded, the scanner reported success, and the resulting report names a few low-impact informational items because the scanner spent the engagement walking the public surface. The headline metric (scan completed, modules executed) flatters the run, and the route inventory gives the failure away only if someone goes looking. By that point the report has shipped and the surface that needed coverage was never tested.

This guide walks through the six authentication failure classes that account for most of the gap, the diagnostic signals that separate them in scanner logs, the fixes that work per class, and how to record the authentication state on the scan so the report can defend the coverage envelope honestly. It does not cover network-layer blocks at WAF or CDN, which sit upstream of authentication and are covered separately in the scanner blocking and allowlisting guide.

How to tell the scan never actually authenticated

Before debugging a specific failure class, the question is whether the scan reached the authenticated surface at all. Three signals separate a scan that authenticated cleanly from a scan that ran with an unauthenticated profile in everything but name.

Route inventory comparison

Run an unauthenticated scan against the same target. If the authenticated scan produced a route inventory of the same shape and size, the scanner never followed a redirect into the protected surface. A clean authenticated scan should expand the route inventory by the application is authenticated tree, not just add a few more paths.

Response code histogram

Authenticated scans hit a healthy mix of 200 and 302 across protected paths. Long runs of 302 redirecting to the login page, or 401 across the same paths, mean the scanner never carried a valid session past the redirect. Scanners that report success without showing this distribution are reporting on the modules they executed, not on the surface they reached.

Finding distribution

An authenticated scan should produce findings on session handling, parameter handling on protected routes, and authorisation behaviour. A finding list dominated by TLS posture, security headers, and public path discovery is the shape of an unauthenticated scan; the finding pattern itself is evidence the authenticated modules never had anything to test.

The six authentication failure classes

Six classes account for most authenticated scan failures in practice. Each one looks like a generic failure in scanner logs and needs a different fix. The table below maps the diagnostic signal to the failure class and to the fix, so the debugging walk has a shape rather than a guess.

Failure class	Diagnostic signal	Fix
Wrong role	Scan completes, but admin paths return 403 or are absent from the route inventory.	Reissue test credentials at the role the scope assumed; record the role on the credential record.
Login script drift	Scanner login step returns 200 but lands on the login page; HTML field IDs changed.	Re-record the login flow, pin field selectors, add a post-login marker the scanner can check.
Session expiry	Scan starts authenticated and degrades to unauthenticated mid-run; back half is mostly 302 to login.	Configure session refresh, shorten scan duration, or pin a longer-lived session token.
CSRF token rotation	Login succeeds, then any state-changing request returns 403 with a CSRF-related error in the body.	Configure per-request token extraction; update the scanner macro to inject the current token.
MFA enforcement	Login form posts cleanly but the next page asks for a second factor the scanner cannot satisfy.	Provision a TOTP-aware scanner profile, pin a session captured outside the scan, or use a non-production environment with documented MFA divergence.
SSO redirect failure	Scanner follows multiple redirects and lands on the identity provider rather than the application; ends with a partial cookie set.	Pre-authenticate outside the scanner, pin the resulting session, or move the test environment to a non-federated identity profile.

The debugging walk is the same in every case: confirm the symptom (route inventory, response codes, finding shape), match the symptom to the failure class, apply the fix, re-run, and verify the symptom is gone. Skipping straight to fixes without confirming the failure class is how scans get cycled with the same problem hidden under different error messages.

Provisioning test accounts that match the scope

Most authenticated scan problems start at the credential issuance step. The scanner is given an account that does not match the scope, and every downstream symptom inherits from that mismatch. The pattern below produces a credential record the scan can defend and the audit can read.

Match the role to the scope. If the scope names administrator surface, the credential is administrator. If the scope names authorisation testing across two roles, two credentials are issued. The role the scanner runs at is part of the scope statement, not an implementation detail.
Dedicate the account to scanning. Test accounts that double as developer accounts have unpredictable password rotation, MFA enrolment, and session histories. A scanner-only account isolates those variables and is safe to drop after the engagement closes.
Decide the MFA posture deliberately. Three options work: TOTP secret given to the scanner, MFA disabled on the test account in a non-production environment with the divergence documented, or interactive pre-authentication outside the scanner with the resulting session pinned. The wrong answer is disabling MFA in production to make scanning easier.
Record the credential against the engagement. The credential issuance event names the role, the environment, the MFA posture, and the scope it was issued for. When a scan fails six weeks later, the record is what tells the team whether the credential drifted, the role changed, or the environment moved.

CSRF tokens, session cookies, and per-request handling

Once the credentials work, two mechanics break authenticated scans even when the login itself succeeded: rotating CSRF tokens and session cookie handling. Both are framework-level behaviours the scanner has to accommodate, not application-level bugs.

Per-request CSRF token extraction

Many frameworks rotate CSRF tokens on every form render. A scanner that recorded the original token and replays it sees its non-GET requests rejected with a 403-style error and a message that often references the token directly. The fix is configuring the scanner to extract the token from each response (hidden form field, cookie, or meta tag depending on the framework) and inject the current value into the next state-changing request. Most commercial scanners support this through response macros or token replay rules; configuring it is a one-time setup per target.

Session cookie handling and refresh

The session cookie is the scanner is authentication credential after the login flow completes. If the cookie has a short lifetime (30 minutes is common, 15 minutes is not unusual) and the scan runs for two hours, the back half of the scan runs unauthenticated. The fix depends on the application: if the scanner can refresh the session through a known route, that is the cleanest path; if not, shorter scan segments with a fresh login per segment, or a longer-lived session token captured manually and pinned, are the practical alternatives.

Session pinning and its trade-offs

Session pinning is the workaround for login flows the scanner cannot automate (heavy JavaScript, MFA, federated SSO with consent screens). A human logs in, the resulting cookie is captured, and the scanner uses that cookie on every request. The trade-off is durability: the pinned session expires, and the scan after that point is unauthenticated. The defensible pattern is short scans, frequent re-pinning, and an explicit record on the scan that names the session lifetime so the report can defend the depth.

MFA, SSO, and federated authentication

MFA and SSO are the two authentication patterns most likely to make automation hard. Both are non-negotiable in modern production environments, and both push the scanner into pre-authentication or session pinning territory. Choosing the right pattern up front is what keeps the scan honest.

TOTP-aware scanner profiles

Where the scanner supports it, holding the TOTP shared secret and computing the second factor on each login attempt is the cleanest approach. The scanner runs a fresh login flow each time, the second factor is satisfied automatically, and the resulting session reflects the production posture. RFC 6238 defines the algorithm, and any scanner that supports recorded macros plus a TOTP secret field can do this without a workaround.

Pre-authenticated session pinning for SSO

For federated SSO that requires consent screens or extra interaction, pre- authenticating in a real browser, exporting the resulting cookie set, and pinning that cookie set on the scanner is the practical pattern. The pinned session has to cover every cookie the application reads (the identity provider session, the application session, any cross-domain anti-forgery cookie) or requests will fail downstream of the login. The scan record names the session lifetime and the re-pinning cadence so the depth is defensible.

Non-production environments with documented divergence

Where MFA and SSO together make scanning impractical, scanning a non-production environment with the authentication posture deliberately relaxed is sometimes the only path. The trade-off is that the scan no longer represents production exactly, and the report has to name the divergence (which authentication features are disabled in the test environment, what that excludes from coverage). A scan against a relaxed environment that ships as a production scan is the failure mode that produces the worst false confidence.

A debugging walk for a scan that came back empty

When an authenticated scan finishes and produces a finding list that looks unauthenticated, the walk below isolates the failure class quickly enough that the scan can be re-run inside the engagement window rather than after delivery.

Pull the route inventory. Compare the authenticated scan inventory to the unauthenticated baseline. If the authenticated inventory is the same shape, the scan never reached the protected surface.
Pull the response code histogram. Long runs of 302 to login or 401 on protected paths point to session expiry or login failure; runs of 403 with CSRF-related error messages point to CSRF token rotation.
Verify the credential outside the scanner. Log in manually with the same credentials. If the manual login fails, the credential is the problem and reissue is the fix. If the manual login succeeds and the scanner fails, the issue is in the scanner is automation harness, not the credential.
Check the post-login marker. Configure the scanner to fetch a known authenticated-only page after login and verify the response contains an expected authenticated marker. If the marker is missing, the scan should fail loudly rather than continue silently.
Inspect the cookie set. After the scanner login step, compare the scanner cookie set to a manual browser cookie set on the same login. Missing cookies usually point to redirect handling that did not complete or SSO that produced a partial session.
Match symptom to failure class. Use the table above to map symptoms to the right fix class. Apply the fix, re-run, and verify the symptoms cleared before the next module batch starts.

Six checks are usually enough to isolate the failure class and queue a fixed re-run. Skipping straight to a re-run with a different scanner profile, without isolating the failure first, tends to produce the same outcome with a different error.

Recording authentication state on the scan

Every authenticated scan should produce a record the report and the audit can read. Four fields cover the bar; missing any of them turns the scan output into informational data rather than authoritative findings.

Scope of the authenticated surface: which routes were in scope at which roles, including any explicit exclusions.
Authentication mechanism: form login, API token, OAuth bearer, SAML SSO, cookie pinning, plus any second-factor mechanism that applied.
Success signal: the post-login marker the scanner relied on to confirm authentication, and whether it fired throughout the run.
Authentication state at end of scan: still authenticated, expired mid-scan with timestamp, never authenticated, partially authenticated by route. Without this, a session expiry mid-scan is invisible to the report.

The record is the difference between a scan that defends in audit and a scan that ships looking complete and unravels under scrutiny. Compliance frameworks that demand authenticated scanning evidence (PCI DSS, ISO 27001 Annex A 8.8, SOC 2 monitoring criteria) read this record more than they read the finding count.

How SecPortal records authenticated scan state

SecPortal stores authentication credentials with AES-256-GCM encryption against the workspace, so the scanner can replay the login flow without a human re-entering credentials each scan. Credentials are scoped to the engagement, and the credential record names the role and the environment they were issued for. This makes the credential lifecycle auditable later, including which scope each credential was authorised against.

The authenticated scanning feature runs seventeen modules covering authentication, session handling, input validation, and API checks. Scanner output lands as draft findings on the engagement record so a tester triages before delivery rather than after. The scanner result triage workflow surfaces scan-record metadata alongside the findings so a scan that ran short of its scope can be flagged before the report ships, and the scanner coverage and limits guide covers how to read the resulting envelope honestly across external, authenticated, and code scanning together.

For the upstream conversation about scope and target selection, the scan scoping and target selection guide covers how to define the authenticated surface and the role boundaries before the credential is ever issued. For the downstream conversation about what to do when findings come back, the scanner false positives guide covers triage and the scanner output deduplication guide covers merging findings across tool outputs without losing evidence.

Network-layer blocks at WAF or CDN are a different failure class that can mask authentication issues; the scanner blocking and allowlisting guide covers where those blocks land in a typical stack. Both questions need to be cleared before a scan that fails authentication can be diagnosed cleanly.

Most authentication failures originate upstream of the scan log, in the credential itself. The scanner credential rotation and lifecycle guide covers rotation cadence, off-cycle triggers, service account discipline, and how to rotate without breaking scheduled scans, which is the upstream policy that prevents most of the failure modes covered above.

Related vulnerability classes that depend on authenticated scan depth

Several vulnerability classes are reachable only from inside an authenticated session. Scans that fail authentication miss them entirely, and reports that ship without the authentication state recorded misrepresent how thoroughly these classes were tested.

Broken authentication: the failure class the scanner cannot test if it cannot authenticate. Treating empty findings as evidence the application has no authentication issues is the wrong read.
Session fixation: detection requires the scanner to manipulate session cookies pre and post-login, which only works when the login flow is fully automated.
JWT vulnerabilities: algorithm confusion and key handling issues require a valid token issued during the scan, which means the authentication harness has to work end-to-end.
OAuth misconfiguration: the scanner needs to participate in the OAuth flow to test redirect URI handling and consent screen behaviour, both of which assume authentication automation that works.
Broken access control: role-aware authorisation testing depends on the scanner running at the right role. A wrong-role authenticated scan looks identical to a no-finding scan from the report perspective.

For the broader context around scanner depth choice, the authenticated versus unauthenticated scanning blog covers the practical depth difference, and the severity calibration research covers how to score scanner-derived findings consistently when the authentication depth varies across cycles.

Scope and limitations of this guide

Authentication failure modes are application-specific in their details and shared in their pattern. The classes covered here account for most of the gap in commercial authenticated scanning, but the exact diagnostic shape depends on the scanner, the framework, and the identity stack. The fixes apply across scanners; the configuration steps differ. The guide leans on signals rather than scanner-specific menus, so the walk applies to any authenticated DAST tool that exposes its login flow, response handling, and session policy.

The objective is not to make every scan succeed unconditionally; some authentication postures resist automation and the right answer is to run scope in a non-production environment with documented divergence, or to handle the surface manually. The objective is to make the failure visible before delivery so the report defends the depth honestly, not after delivery when a finding shows up in production that the scan never had a chance to catch.

Frequently Asked Questions

Sources

Run authenticated scans on a record that names the auth state

SecPortal stores credentials encrypted against the workspace, runs seventeen authenticated modules, and records scope, role, and authentication state on every scan so the report can defend the depth before delivery.

Start free See authenticated scanning