Not by design. CAPTCHA and multi-factor prompts exist to stop automation, so a scanner cannot be expected to defeat them. The workable approach is to give the scanner a path in on a test environment, such as a scan-only account, a token, or a controlled bypass, while keeping those protections on in production.
Why this comes up
A scan that cannot log in tests only the public surface. Most of the risk lies behind the login. Yet login pages are where teams place their strongest anti-automation controls. The result is a quiet failure: the scanner sees a challenge page, records nothing, and the report looks clean.
Definitions
- CAPTCHA: a challenge meant to tell people from programs.
- MFA: a second proof of identity, such as a code from an app or a message.
- Scan account: a dedicated test user created only for scanning.
- Bypass: a controlled way for a named test account to skip a challenge in a non-production environment.
Options at a glance
| Option | How it works | Risk | Fit |
|---|---|---|---|
| Provide a token or session directly | Supply a valid token the scanner sends in a header | Token must be short-lived and test only | Good for APIs |
| Scan-only account with MFA turned off | The account skips the second step in staging | Must not exist in production | Common and simple |
| Test mode for the challenge | The CAPTCHA provider offers a test key that always passes, on staging | Must be switched off elsewhere | Good for CAPTCHA |
| Recorded login with a fixed test code | Authenticator seed shared with the scan job | Seed must be protected | Works when MFA cannot be removed |
| Skip the login and test what you can | No setup | Low coverage | Last resort |
Check your own tool's documentation for the login methods it supports. ZAP's documentation, for example, lists browser based authentication and OAuth2 authentication among its features, which suggests the range of approaches modern scanners offer, though what works depends on your login design.
Steps
- Decide the environment. Do this on staging or a dedicated test environment, not production.
- Create a scan account with the lowest rights that still reach the pages in scope.
- Choose a method from the table, based on what your login uses.
- Make the bypass conditional. Tie it to the account name or a setting that only exists in non-production configuration.
- Verify login. Add a check that proves the session is valid, such as text that appears only when signed in.
- Watch for lost sessions. If the scanner is logged out mid scan, the check should trigger a login again.
- Record the method in the scan record, so a reader knows what was tested.
- Remove the exception or keep it locked down after the run.
A worked example
A team's staging login asks for a password and a six-digit code. The first scan reports no findings behind the login, and the log shows 302 redirects to a code entry page for every request.
They create a scan account with a flag in the staging configuration that marks it as exempt from the second step. They add a verification check for the account menu text. They rerun and the scanner reaches 180 authenticated routes where it reached 12 before. The numbers are illustrative.
Then they test the other side. In a separate manual test, they confirm the exemption flag does not exist in the production configuration, and that a normal account still needs a code. They record both checks.
Risks to manage
| Risk | Control |
|---|---|
| Bypass left on in production | Configuration test in the release pipeline that fails if the flag exists |
| Shared secrets in scan jobs | Store in a secrets manager with limited access and rotation |
| Scan account with too many rights | Least privilege, reviewed each quarter |
| Teams forgetting the scan was exempted | Note the exemption in the scan record and the report |
Testing the protections themselves
Removing a challenge for the scanner does not mean you stop testing it. Test CAPTCHA and MFA separately: try repeated failures, replayed codes and skipped steps by hand. These are logic problems that automated scans handle poorly, as the OWASP testing guidance on business logic and authentication explains.
What to say in reports
State plainly how login was handled: "scanned as a scan-only account with the second factor exempt in staging". Readers can then judge what a clean result covers.
Handling single sign-on
Many companies use an external identity provider, so the scanner never sees a password form on your own site. The login happens on another domain, which should be out of scope for attack traffic. Two workable patterns exist. One is a test tenant at the provider with a scan-only user, where the scanner completes a recorded login flow. The other is to skip the interactive login and have the application accept a short-lived token minted for the test environment. Whichever you choose, keep the provider's pages out of the attack scope and note in the record which side of the login was tested.
Keeping the exemption honest
An exemption is a hole you dug on purpose. Put a reminder on the calendar to review it each quarter, list who knows about it, and write one automated check that proves it is absent in production. If you cannot check it automatically, add it to the release checklist. Teams that skip this step eventually find, during an unrelated incident, that a test shortcut shipped to production years ago.
Where Safeguard fits
Login handling is a web testing matter. For the open source libraries behind your login and the rest of the app, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the point where the scan needs to authenticate, and think about which method from the table would apply to your login.
Quick check
Should I turn off MFA in production so scans work?
No. Use a staging environment with a scan-only exemption, and keep production protections on.
How do I know the scanner was really logged in?
Add a verification check, such as text only shown to signed-in users, and review the log for redirects to the login page.
Does skipping CAPTCHA in staging mean CAPTCHA is untested?
It can. Test the challenge separately by hand, including repeated failures and skipped steps.
Sources
Last reviewed: 19 October 2026.
