How Decloak Scans Behind a Passkey Login (When There's No Credential to Script)
Most of what a security scanner can see is limited by what's public. The moment real functionality sits behind a login, a dashboard, an account settings page, an internal tool, most scanning stops right there, at the login form, because there's no straightforward way to get past it automatically.
Decloak's authenticated scan mode solves this differently than the obvious approach, and the reason why matters.
Why scripting a login isn't always an option
The conventional way a scanner gets past a login is to script it, store a username and password, submit the form, capture the resulting session cookie, and proceed. That works fine for traditional password-based authentication. It doesn't work at all for passkeys.
WebAuthn, the standard behind passkey authentication, is built specifically so there's no credential to store or script in the first place. A passkey ceremony requires what the specification calls an authorization gesture, a physical interaction on the actual authenticating device, biometrics, a hardware key, a device PIN, that happens inside a browser session and produces a cryptographic signature tied to that specific origin and challenge. There's no password sitting in a database to paste into an automation script, because the entire design goal of WebAuthn is to remove exactly that.
That's a genuine security win for the sites using it. It's also, structurally, a wall for any scanner that only knows how to script a login form.
How session capture gets around it
Rather than trying to automate the login itself, Decloak's authenticated scan mode captures a session you've already logged into, through a browser extension, and hands that live, already-authenticated session to the scanning agent. You log in normally, the way you always would, passkey, password, SSO, whatever your site actually uses, and the extension captures the resulting session state for the agent to crawl with.
This sidesteps the entire scripting problem, because nothing needs to be scripted. The agent isn't trying to reproduce a login ceremony it fundamentally can't reproduce, it's working with a session that's already past that point, the same way a real logged-in user's browser would be.
What this actually unlocks
Once a session is captured, the full agent crawl runs against everything that session can reach, dashboards, account pages, internal tools, anything gated behind login that would otherwise be entirely invisible to a scan. All 8 layers, plus Active Testing and AI Pentesting where enabled, run against authenticated pages exactly as they would against public ones.
For a lot of real applications, this is where the majority of the actual attack surface lives. A marketing site's public pages are one thing. The logged-in product, the part your paying users actually interact with every day, is usually both larger and higher-stakes, and it's the part a scanner that stops at the login page never sees at all.
Why this is worth calling out specifically
Passkey adoption has grown fast, and for good reason, it's phishing-resistant in a way password-based auth structurally isn't. But that same design, no stored credential, a per-origin cryptographic ceremony, means a lot of security tooling built around scriptable logins simply doesn't work against it. Session capture isn't a workaround bolted on for passkeys specifically, it's the same mechanism regardless of what your login flow actually is, which means it doesn't break the day you migrate to passkeys, or the day you add SSO, or any other authentication change down the line.
Availability
Authenticated scan mode is available on Decloak Enterprise, capturing a session via browser extension for the agent to crawl behind.
Authenticated scan mode is available on Decloak Enterprise. See plans →