Authenticated vs Unauthenticated Pen Testing: What the Login Changes

The login does not make a penetration test better. It makes it answer a different question.

An unauthenticated test asks whether somebody with no account can get in or get data out. An authenticated test assumes they already have a working login, by theft, phishing or a disgruntled employee, and asks how far that login goes.

Both are real tests. They find different categories of problem, and buying the wrong one for your situation is the expensive mistake. So here is the split, and then exactly which side of it our $495 test sits on, because that part is usually left vague in posts like this.

What each one actually simulates

Unauthenticated, from outside. The tester has what the internet has: your domain name. No account, no documentation, no help. Everything found this way is reachable by anyone who can type your URL, which is why these findings tend to be urgent even when they are technically small.

Authenticated, with credentials. The tester is given accounts, ideally one per role, and works from inside the product. This models the attacker who bought a session cookie off a market, or the contractor whose access was never revoked.

The second scenario is not hypothetical. Credential theft is one of the most common ways real incidents start, which is the honest argument for authenticated testing: a test that stops at the login page stops exactly where a lot of real attacks begin.

Call it grey box, not white box

An authenticated test with a couple of accounts and some docs is grey box. White box means the tester has source code and architecture diagrams. Vendors blur these two constantly, usually in the direction that makes the quote look bigger. If somebody sells you a white box test and never asks for repository access, you are buying grey box with a markup. We wrote about the three boxes in more detail here.

What only shows up after the login

These are the findings that need credentials. No amount of outside scanning produces them, and anyone claiming otherwise is guessing:

• Broken object level authorisation. You change an id in a URL or a request body and get back somebody else's record. In a multi-tenant product this is the finding that ends deals, and it is invisible from outside because you need two valid accounts to prove it.
• Privilege escalation between roles. A read-only user reaching an admin function, usually because the UI hides the button but the API does not check.
• Over-privileged accounts and tokens. What an API key can actually do versus what it was issued for.
• Business logic abuse. Applying the same discount twelve times, skipping a payment step, editing an order after dispatch. This needs a person who has learned how your product is meant to work.
• Internal-only features. Anything behind the login that calls an internal API on the user's behalf, which now includes most AI assistant and agent features people shipped this year.

Notice what these have in common: they are authorisation bugs. An authenticated test is mostly an authorisation test, and authorisation is where custom application code goes wrong far more often than authentication does.

What the unauthenticated test genuinely buys you

The reason to run the outside test first is not that it is cheaper. It is that its findings are exposed to everybody, right now, with no prerequisite. A missing authorisation check needs an attacker with an account. An exposed admin panel needs an attacker with a browser.

What the outside view reliably surfaces:

• Services and ports that should not be reachable from the internet, including the database, the staging copy and the forgotten subdomain.
• Endpoints that should require authentication and do not. This is the overlap case, and it is worth its own sentence: an access control bug on an unauthenticated endpoint is findable from outside, and it is usually the worst one in the report.
• Known vulnerable software versions at the edge. The last two months of PHP and Node issues were all exploitable with no login at all.
• TLS and certificate problems, weak protocol support, certificates about to expire.
• Session and cookie handling visible on the login flow itself: missing Secure and HttpOnly flags, missing HSTS on a site that carries sessions.
• Information leakage that helps the next attacker: verbose errors, exposed configuration, directory listings, debug endpoints left on.

That list is also most of what an automated attacker is scanning the whole internet for. Fixing it does not make you secure against a targeted adversary, and it does take you out of the opportunistic sweep, which is what actually hits small companies.

What the Fast Pen Tests $495 test supports

Plainly, so you can decide in one read: the standard test is an external, unauthenticated, black box assessment of one hostname. We do not log in. The report says so in its own limitations section rather than letting you assume otherwise.

What is in scope and runs on every job:

• Port and service discovery against the host, to find what is listening that should not be.
• TLS and certificate assessment: protocol versions, cipher support, certificate chain and expiry.
• Templated vulnerability checks for known issues, exposed panels, misconfigurations and leaked files, plus web server level checks for dangerous defaults.
• HTTP security header and cookie flag review on the responses your site actually returns.
• DNS and target validation, so the thing we tested is provably the thing you asked us to test.
• Human review before delivery. A person reads the raw tool output, drops the noise, and keeps findings only where the evidence supports them. Every finding quotes the evidence it came from.

Two limitations we write into the report rather than hiding:

• The login layer is not tested. Everything in the section above about authorisation bugs is outside this scope, and the report states that it is.
• A provider-managed edge limits coverage. If Cloudflare or similar challenges the scan, some checks cannot complete. We report that as a stated limitation, because a blocked scan looks exactly like a clean site and we are not willing to let that pass for a clean bill of health.

Also not included: mobile apps, internal networks, cloud configuration, source code review and social engineering. The full scope post goes through all of it, including when you should spend ten times more with somebody else.

If your risk genuinely lives behind the login, complicated roles, multi-tenant data, an admin panel that can see everything, then you want a grey box engagement with accounts per role. That is a quote, a scoping conversation and a longer calendar, not a $495 product. Telling you that is cheaper for us than selling you the wrong test and handling the refund.

Which one your auditor or customer means

The word on the questionnaire is usually just “penetration test”, so check what the underlying requirement says:

• PCI DSS splits it. Requirement 11.4.3 is external penetration testing; 11.4.2 is internal, performed from inside the network, which in practice is a credentialed engagement. An external test does not satisfy the internal line item.
• SOC 2 does not mandate either one. Your auditor decides what satisfies the control, and an annual external test with evidence of remediation is commonly accepted. We went through this in its own post.
• A customer contract is the one that most often specifies authenticated testing of every user role by name. If it does, that is binding and no amount of external testing substitutes. Read the clause before you buy anything.
• GDPR and similar require testing without naming a method. Our UK requirements post covers how that works in practice.

How to decide this week

1. Read the actual requirement, whether that is the contract clause, the SAQ or the questionnaire. If it says authenticated or internal, stop here and scope that.
2. If it does not, ask where your risk sits. Mostly a marketing site and a thin app? The outside test covers the realistic threat. A multi-tenant product holding other companies' data? The authorisation bugs are your real exposure.
3. Never done either? Do the external one first. It is faster, it finds the things already exposed to everyone, and it tells you whether your perimeter is even worth defending before you pay for depth.
4. Doing the authenticated test later? Start preparing now: a test account per role, written expectations of what each role should be able to do, and a staging environment. Most delays in those projects are account provisioning, not testing.

The free scan gives you the outside view of your domain in a couple of minutes, with no account and no call. If the result is ugly, you know where to start and you have not spent anything to find out.