Authenticated vs unauthenticated testing: which one to choose first
Start with unauthenticated testing when your exposed perimeter is the main unknown and you have no accounts to give a tester yet. An outside view shows what an anonymous attacker can reach on the internet-facing hosts, login pages and exposed APIs, and it is the cheapest way to find what should not be public at all. For a PCI DSS or similar assessment, though, that result is only a first pass. Unauthenticated work cannot show whether a logged-in customer can read another customer's records or whether a standard user can reach an administrative function, so it does not answer the questions an assessor will ask about application roles.
Move to authenticated testing once your applications have role-based access, once you run internal scans, or once you have any reason to worry about privilege escalation. For internal vulnerability scanning, PCI DSS requirement 11.3.1.2 expects authenticated scanning with sufficient privileges, and it requires you to document any system that cannot accept credentials. Some network appliances, mainframes and containers may not accept credentials at all, so confirm that list with your assessor early. For applications, PCI SSC guidance says testing should cover every role or access type, including roles with no access to cardholder data. Provision one test account per role, scoped to the least privilege that still exercises the function, and record who owns each account and when it expires.
For most regulated teams the answer is to combine both, with unauthenticated testing first for the perimeter and authenticated testing for every role. Run the outside view early so exposed services are fixed before testers spend time behind login, then give the authenticated testers the credentials needed to check privilege escalation. Ask your provider to state in the written scope which roles, accounts and systems will be tested with credentials, and which will be tested without them, so the gaps are visible before work starts.
Side-by-side: goals, access, coverage and evidence
This table compares authenticated and unauthenticated testing of applications and infrastructure across goal, starting access, reach, findings, gaps, tooling, manual work, remediation and evidence. Read each row as the trade-off a team accepts by choosing one viewpoint, then combine both where the target has login-protected roles or privileged infrastructure. The main takeaway is that unauthenticated testing shows what an outsider can reach, while authenticated testing shows what a user or admin can do once inside.
| Factor | Unauthenticated testing | Authenticated testing |
|---|---|---|
| Primary goal | Show what an anonymous outsider can reach, exploit or learn about the target | Show what a user with a given role, or an admin, can access, change or escalate to |
| Starting access | No account, credentials or prior foothold | Valid accounts for each role, or scanner credentials with sufficient privileges |
| Reach into the application | Public pages, login forms, exposed APIs and anything served before authentication | Role-gated functions, workflows, data objects and admin consoles behind the login |
| Reach into infrastructure | Open ports, exposed services and banners visible from the tested network path | Installed packages, patch levels, local configuration and missing hardening on hosts |
| Typical findings | Exposed services, weak or missing transport settings, injection on public inputs, default pages | Broken access control, privilege escalation between roles, missing patches, insecure local settings |
| What it misses | Flaws that only appear after login, role-specific authorization gaps and most host-level weaknesses | Internet-facing exposure that depends on what an anonymous visitor sees, and issues that only the credentials hide |
| Tooling and automation fit | Network discovery and scanners without credentials handle broad coverage well | Credentialed scanners and authenticated crawlers give deeper coverage but need account and session handling |
| Role of manual work | Testers validate exposed behavior and confirm which findings are reachable | Testers compare what each role can do, test object-level and function-level access and confirm escalation paths |
| Remediation focus | Close exposure, harden public endpoints and remove unneeded services | Fix authorization logic, patch installed components and tighten role design |
| Evidence produced | Port and service inventory, unauthenticated scan output and validated exposure notes | Scan records showing credentials used, role-by-role test results and documented systems that rejected credentials |
What each approach finds and misses
Unauthenticated and authenticated testing answer different questions about the same system. The cards below set out what each viewpoint sees, what it cannot see, and which blind spot a team should close with the other approach.
Unauthenticated testing of internet-facing surfaces
An anonymous tester sees what any outsider sees: DNS names, open ports, TLS configuration, login pages, public APIs and error responses. This view shows how easily an attacker can reach the perimeter and what information leaks before anyone signs in. It misses everything behind a login, including role checks, object-level access and workflows that only appear after authentication. Check that the scope lists every public hostname, including forgotten staging and partner endpoints, and confirm whether the tester may attempt login with a supplied account only when the client asks for it.
Authenticated testing of application roles
Testing with accounts for each role, such as customer, agent, administrator and read-only auditor, is where broken access control usually surfaces. A tester can request another user's records by changing an identifier, or call an administrative function from a standard account. PCI SSC guidance asks that every role or access type be covered, including roles without access to cardholder data, and encourages supplying credentials so testers can check for privilege escalation. Confirm that each role in the requirements matrix has an account and that test data belongs to separate users.
Credentialed scanning of hosts
NIST SP 800-115 notes that some network-based scanners use administrator-level credentials to extract vulnerability information from hosts. With credentials, a scanner can read installed package versions, local configuration and missing patches, which an outside view cannot determine. Without credentials, the scanner mainly performs network discovery and identifies open ports and related services. The limit is that some network and security appliances, mainframes and containers may not accept credentials, so those systems need a documented exception. Ask the provider which hosts were scanned with credentials and which were not.
Unauthenticated network discovery
Scanning without credentials answers a narrower question: what does the network expose to a host that has no account? It finds reachable services, version banners and some known weaknesses, and it confirms what segmentation blocks from an untrusted position. It is useful for inventory and for checking that an unexpected service is not reachable. It cannot confirm patch levels or local settings, so a clean result does not mean a host is patched. Compare the discovered inventory with the asset register before treating the results as complete.
Blind spots of the outsider view
An anonymous test misses local misconfigurations, weak file permissions, unpatched packages that expose nothing on the network, and application logic that requires an account. Teams often read a clean external result as proof that the application is secure. The gap matters most where a compromised employee laptop or a low-privilege account is the realistic starting point. Ask whether the test plan states which findings are out of reach from outside and whether an authenticated test covers them.
Blind spots of the insider view
A tester with valid credentials sees what that account can reach, so results depend on the accounts supplied. Internet-facing weaknesses such as unpatched edge devices, exposed administrative interfaces and misconfigured cloud storage can be missed if the test starts inside the network. Authenticated tests also miss what they never request, such as roles nobody provisioned. Confirm that the internal and external viewpoints are both planned, and that the account list is recorded in the rules of engagement.
How PCI DSS 11.3.1.2 and PCI SSC guidance shape authenticated testing
Requirement 11.3.1.2 makes authenticated internal vulnerability scanning mandatory, and it became mandatory on 31 March 2025 under PCI DSS v4.0. The requirement asks for internal scans to run with credentials and sufficient privileges, so the scanner can see installed software, patch levels and configuration that an unauthenticated scan cannot reach. It also asks you to document every system that cannot accept credentials and to manage the scan accounts that allow interactive login under requirement 8.2.2. The applicability note recognizes that some network and security appliances, mainframes and containers may not accept credentials. Those exceptions need a written record, and the record should state the compensating view you use instead, such as a network-based scan or a vendor-supported management interface. Confirm with your assessor which in-scope components fall into this exception list before the first scan cycle.
PCI SSC's penetration testing guidance adds a second expectation: when an application requires authentication, testing should cover every role or access type, including roles that never touch cardholder data. A low-privilege customer account can be the entry point for a privilege escalation path into an administrative or support function, so a test run only as an anonymous user or one standard user misses that path. The guidance strongly encourages supplying test credentials for each role so testers can check for privilege escalation. Build a role matrix for each in-scope application, provision one dedicated test account per role with the least privilege that role needs, and record who approved each account and when it expires. For NIST SP 800-53 users, control enhancement RA-5(5) Privileged Access calls for privileged access authorization for vulnerability scanning and appears in the moderate and high baselines. Ask your assessor how these expectations map to your defined scope, because the answer determines which roles and systems the evidence must cover.
Which application roles to test and why
Customer-facing web roles, such as a retail user, a business account member or a tenant administrator, are where most data separation problems sit. An anonymous test can confirm that login, password reset and session handling resist basic abuse, and that unauthenticated pages do not expose records. Only a test with a valid account can check whether one customer reaches another customer's data, which is horizontal privilege escalation, or whether a standard user reaches functions reserved for a higher role, which is vertical privilege escalation. PCI SSC guidance says that when an application requires authentication, testing should cover all roles or access types, including roles without access to cardholder data, and it strongly encourages organizations to supply credentials so testers can check for privilege escalation.
- Horizontal access: Two accounts at the same privilege level, each owning separate data, to check object references and tenant boundaries.
- Vertical access: A low-privilege account attempting administrative functions, exports and configuration changes.
- Data exposure: Responses that return more fields or records than the screen shows the user.
- Anonymous first checks: Login throttling, account enumeration and session token strength before any credentialed work.
- Test data: Confirm with the provider that accounts hold realistic but non-sensitive records.
Confirm in the written scope which customer roles and tenant types are named, and how many test accounts per role the client will supply.
Administrative and back office roles, such as support agents, finance operators, content managers and platform administrators, hold functions that can change other users' data or system settings. An anonymous outsider rarely reaches these screens, so an unauthenticated test will not reveal whether a support role can view data beyond its duty or whether an administrative function is protected only by the interface rather than by server-side checks. A credentialed test at each back office level shows what that role can actually do, and whether it can escalate to a higher one. Because these accounts are powerful, the test should prove that access is enforced where the data lives, not only in the menu.
- Role boundaries: Each back office role mapped to the functions it should and should not reach.
- Function-level checks: Direct requests to administrative endpoints from a lower role.
- Audit trail: Whether privileged actions made during testing are logged, so the client can separate test activity from real misuse.
- Break-glass access: Emergency or support accounts that sit outside normal role design.
- Anonymous first checks: Confirm admin paths are not reachable without a session.
Confirm with the provider whether administrative roles are in scope, who holds the credentials, and how the client will verify the logs.
API clients often authenticate with tokens tied to a scope, a client identity or a delegated user. Testing these with one token tells you little about the others, because authorization may be checked per endpoint, per scope or per object. An anonymous test can confirm that unauthenticated requests are rejected and that error responses do not leak internal detail. A credentialed test with each client type, each granted scope and at least one token belonging to a different user is needed to see whether a narrow scope can call broader operations, or whether an expired or revoked token still works. The OWASP WSTG describes testing in this area as part of its broader guidance on authorization and session management.
- Scope mapping: Each client and granted scope compared with the endpoints it should reach.
- Cross-user tokens: Using one user's token to read another user's objects.
- Token lifecycle: Expired, rotated and revoked tokens tested against live endpoints.
- Machine clients: Service accounts with broad permissions and no human owner.
- Anonymous first checks: Unauthenticated access to every documented and undocumented route.
Confirm in the written scope which API clients, scopes and token types are covered, and whether the provider receives the API specification.
Infrastructure accounts include domain users, local administrators, database service accounts, hypervisor users and scanning credentials. NIST SP 800-115 notes that some network-based scanners use administrator-level credentials to extract vulnerability information from hosts, while scanners without credentials mainly perform network discovery and identify open ports and related vulnerabilities. Authenticated internal scanning under PCI DSS requirement 11.3.1.2 follows the same logic, and the applicability notes say some network and security appliances, mainframes and containers may not accept credentials. Where credentials are not accepted, the client must document that gap. Scan accounts that allow interactive login are also subject to requirement 8.2.2, so they need the same controls as other accounts.
- Scan credentials: Privileged enough to see patch and configuration state, with access limited to scanning hosts.
- Unsupported targets: Appliances, mainframes and containers documented as unable to accept credentials.
- Interactive accounts: Scan accounts that can log in are managed under requirement 8.2.2.
- Privileged access: NIST SP 800-53 RA-5(5) calls for privileged access authorization for scanning in the moderate and high baselines.
- Anonymous first checks: External exposure of management interfaces and remote access services.
Confirm with the provider which credential type, scope and rotation process will be used, and where the client must record systems that cannot accept credentials.
How to provision test accounts safely
This sequence gives the client a written, traceable and time-limited set of test identities so that authenticated testing covers every role without leaving standing access behind.
Agree the test roles in writing
The client's security lead and application owner list every role and access type the tester must reach, including roles with no access to cardholder data, and record the list in the rules of engagement. The tester confirms the list covers the privilege levels they are expected to test for escalation. Done means a signed role matrix exists that both parties can point to later. Ask your identity team which roles exist in the identity provider and whether any are created only by manual process.
Create dedicated, time-boxed test accounts
The identity administrator creates separate test accounts for each agreed role, named so they cannot be confused with production users, and does not reuse existing employee or service identities. Where the environment allows, accounts are created in a non-production tenant or a copy of production data, and each account carries an expiry date set in the identity provider. Done means every account is visible in the directory with its role and expiry attributes. The exact mechanics depend on the identity provider and the client's own controls.
Apply least privilege to each account
The identity administrator grants each test account only the permissions its role needs for the scope in the rules of engagement, and no more. For authenticated internal vulnerability scans, the scanning account needs sufficient privilege to read the configuration and patch state it is meant to assess, which NIST SP 800-53 control RA-5(5) describes as privileged access authorized for scanning. Done means an access review shows each account's effective permissions and a second person has approved them.
Restrict interactive login and tie scan accounts to PCI DSS 8.2.2
Where a scan account must log in interactively, the team limits it to the systems and times named in the plan, enforces the client's strongest authentication method, and records the account in its account management process. Under PCI DSS requirement 8.2.2, accounts that allow interactive login are managed like any other privileged account, so the client keeps an inventory and an owner for each one. Done means the scan accounts appear in that inventory with a named business owner. Confirm the specific controls with your assessor and identity team.
Record who holds each credential
The engagement lead keeps a credential register that lists each test account, the tester who holds it, the date it was issued and the systems it can reach. Credentials are delivered through the client's approved secret store or a secure channel, never in an email or a shared document. Done means the register matches the directory and each tester has acknowledged receipt in writing. Ask the provider how it handles credentials between testers and whether individual tester accounts are used.
Log tester activity throughout
The client's security operations team enables audit logging on the test accounts and marks the test window so that tester actions can be separated from attacker activity. Logs are reviewed during the engagement, and any login outside the agreed window or system list is escalated to the engagement lead. Done means the logs can be tied to the tester identities in the register. Confirm with your monitoring team which logs and retention periods already apply to privileged accounts.
Rotate and revoke credentials at close
When testing ends, the identity administrator disables or deletes each test account, rotates any shared secrets the tester used, and removes temporary group memberships. The engagement lead checks the register against the directory and records each revocation with a date. Done means no test account remains active and the closure record is kept with the test report for audit evidence. Ask the provider to state in the quote who performs revocation and how it is verified.
What drives cost and effort for each approach
Authenticated testing costs more to scope and run than anonymous testing because every role, identity model and credential-free target adds work. The drivers below act in parallel, so a quote that ignores any one of them will usually understate effort.
Number of roles and environments
Every application role, access type and environment is a separate test path. PCI SSC guidance expects testing to cover all roles, including those without access to cardholder data, so a tester must walk each privilege level and check for escalation between them. Ask the provider how many roles and environments are in the quote and whether staging and production are both covered.
Identity model complexity
SSO, MFA, federated logins and multi-tenant isolation each require extra setup before a tester can reach the application. Each MFA factor needs a plan for test use, and each tenant may need its own accounts to check that one customer cannot see another's data. Confirm who configures these identity pieces and whether that effort is inside the fixed scope.
Hosts and appliances without credentials
Some network appliances, mainframes and containers do not accept credentials, so they can only be tested from the outside in. NIST SP 800-115 notes that scanners without credentials mainly perform network discovery. Those targets still need documented coverage and often separate manual work, so ask the provider to list them and to price them as a distinct line.
Manual versus automated depth
Automated authenticated scans are repeatable and cheap to rerun, but logged-in exploitation, privilege escalation and business logic checks are manual work. PCI SSC states that running an automated tool alone does not satisfy the penetration testing requirement. Ask which share of the effort is tester-driven and which is tool output.
Retesting after fixes
Each remediation cycle adds retest effort, and authenticated retests often repeat the account setup. Costs grow when fixes span several roles, because the tester must recheck each path rather than only the one that failed. Ask whether retests are included in the fixed scope and how many rounds the quote assumes.
Client effort to provision and answer
Accounts, test data, role definitions and rules of engagement come from your team, and questions during testing wait on their answers. This effort is paid in internal staff time, not to the provider, and it is often the first thing that slips. Agree on a named owner for account provisioning, a response window and a process for rotating or disabling test credentials at the end.
Questions buyers ask before choosing authenticated testing
Is unauthenticated testing enough for an application that has logins?
No, not on its own. An outside-in test without credentials sees only what an anonymous visitor can reach, so it often misses flaws that sit behind a login, such as broken access control between user roles, insecure object references and privilege escalation. PCI SSC guidance says that when an application requires authentication, testing should cover all roles or access types, including roles that have no access to cardholder data, and it strongly encourages supplying credentials so testers can check for privilege escalation. Unauthenticated testing still has a place for the public perimeter and login pages. Most teams run both, and the written scope should state which roles are in and out.
What does the testing team need from us before work starts?
The team needs working test accounts for every role the application offers, a description of what each role is allowed to do, architecture and API documentation where it exists, and a named contact who can approve actions that could affect live users. Ask the provider to list these inputs in the written scope so gaps are found before the test window opens. Confirm also who owns the accounts after the engagement, how credentials are passed (never by email), and when they are disabled. Missing roles are the most common reason authenticated coverage falls short, so ask the provider to confirm the role list in writing.
How long does provisioning test accounts take, and what slows it down?
No researched figure is available for this, so confirm the timeline with the provider and in the written scope rather than relying on a general estimate. Provisioning usually depends on how many roles exist, whether accounts must be created by an identity team under change control, whether multi-factor authentication or single sign-on needs a test path, and whether accounts must match production data or can use synthetic records. Each of these adds coordination steps. Ask for the dependencies to be listed with an owner for each, and for the start date to follow the date the accounts are confirmed working.
Can our own team run authenticated scans, and what does PCI DSS expect of the scan account?
Yes, if your team has the skills, tools and approvals. Requirement 11.3.1.2 of PCI DSS v4.0 calls for internal vulnerability scans to use authenticated scanning with sufficient privileges. Under requirement 8.2.2, any scan account that allows interactive login must be managed like other accounts. Scanners can be host-based or network-based, and some network appliances, mainframes and containers may not accept credentials, so those systems must be documented. Because the account has elevated rights, restrict its use to scanning, record who holds it, and rotate its secret under your standard process. Requirement 11.3.1.2 became mandatory on 31 March 2025.
What should we ask a provider to include in a quote for authenticated testing?
Ask for a written scope that names each application, role, environment and API in the test, plus the testing approach (manual, automated or both). Request the deliverables, the number of retest rounds included, the rules of engagement, and the named people on both sides. Ask how test accounts will be handled, stored and removed, and what happens if a role cannot be tested. DeployOpen does not publish a price list. Its quotes follow from the written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Compare quotes on the same scope rather than on headline totals.
Does a passing unauthenticated scan satisfy requirement 11.3.1.2?
No. Requirement 11.3.1.2 is about authenticated internal scanning, so an unauthenticated scan does not meet it, even if the result is clean. A scan that runs without credentials mainly performs network discovery and identifies open ports and related vulnerabilities, according to NIST SP 800-115. Authenticated scanning is needed to see installed software, missing patches and local configuration. If a system cannot accept credentials, you must document it under the requirement. Confirm the exact scope of your own assessment with your qualified assessor before relying on any scan report as evidence.
Does authenticated testing change the risk to production systems?
It can. Authenticated testing gives testers more reach, including access to functions that change data, so the rules of engagement should limit which actions are allowed and where they run. NIST SP 800-115 notes that penetration testing uses real exploits against production systems and data and carries high risk, while review techniques pose minimal risk. Agree on test data, blocked actions such as payments or account deletion, rate limits, and a stop condition. Ask whether a staging copy with matching roles is available, and what differences from production would limit the findings.
Combining both approaches in one program
One testing viewpoint rarely gives a complete picture. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and the OWASP Web Security Testing Guide v4.2 states that no single technique is enough. A practical sequence starts with an unauthenticated view of what an outsider can reach, then adds credentials to the same targets. Next, run a credentialed internal scan that meets PCI DSS requirement 11.3.1.2, which covers scan accounts, sufficient privileges and documented exceptions for systems that cannot accept credentials. Last, give testers an account for every application role so that privilege escalation paths are checked. Before any of this starts, decide who approves the test accounts and who tracks their creation, use and removal.
The phases should feed each other, and that is where most of the value sits. Unauthenticated results show which login pages, APIs and remote services are exposed, so those become the first targets for credentialed testing. Authenticated scan output then confirms missing patches and configuration weaknesses that the outside view could not see. Scanners without credentials mainly perform network discovery, so any host that cannot accept credentials should be recorded as an exception with a compensating manual check in the penetration test. When testers chain a low-privilege account into an administrative function, that path should go back into the scan configuration and the role inventory so the next cycle covers it.
Detection validation closes the loop. CIS Controls Assessment Specification, Control 18 covers Safeguard 18.4, which asks that security measures be validated after each test so that detections cover the techniques testers used. In practice, give the security operations team a dated record of which accounts were used, which roles were tested, which source addresses and tools appeared and which techniques were attempted. Then check whether logs and alerts captured each one. Confirm with the monitoring team how they will separate authorized test activity from genuine attacks without disabling detections. In any quote, ask whether credentialed phases, account handling and the detection review are inside the fixed scope, since each adds tester time and coordination.
How DeployOpen scopes, delivers and supports security testing
DeployOpen plans and runs security testing inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For authenticated versus unauthenticated work, we agree in writing which roles, accounts and access levels are in scope before any testing begins.
How we scope
- Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists each application role and access type that testers will use, including roles without access to cardholder data where relevant.
- We confirm which hosts accept credentials and which cannot, so authenticated and unauthenticated coverage is documented per system.
How we build
- Test accounts are provisioned in the client's environment with least-privilege settings agreed during scoping.
- Credential handling, account ownership and removal dates are recorded so scan and test accounts do not outlive the engagement.
- Testing covers the unauthenticated outsider view and the authenticated view for each role, with results kept separate for comparison.
How we hand over
- Deliverables document what was tested with which account, which systems could not accept credentials, and why.
- Findings are reported with reproduction steps, so your team can confirm privilege escalation paths and retest after fixes.
- Evidence is organized for your internal auditors or assessors, who make their own determinations about compliance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so authenticated coverage can follow role and application changes.
- Retainer scope, such as re-provisioning test accounts after a release, is agreed in writing with your team.
- Ask your DeployOpen contact to confirm the scan account review cycle and the escalation path for credential issues before signing.
