The W3C WebAuthn Level 3 Recommendation defines the public-key registration and authentication ceremonies behind passkeys. Those ceremonies are a major improvement over reusable passwords, but their security depends on what the application verifies and how it manages the account around them. The OWASP Passkey Security Cheat Sheet explicitly calls out account binding, recovery and sessions as separate concerns. An enterprise rollout deserves a test plan that follows the entire account lifecycle.
Quick answer. A passkey penetration test should prove that only a credential registered to the intended account can authenticate at the intended origin, under the required user-verification policy. It should then test credential addition and removal, recovery, fallback and the application session created after login. Stingrai can scope a human-led web application and identity assessment around those boundaries and provide reproducible evidence for the rollout decision.
This is a buyer matrix for product owners, security leads and procurement teams commissioning a test of their own application. It is an editorial translation of the W3C specification, OWASP guidance and NIST digital identity guidance. It is not a certification checklist or a claim that those bodies require a penetration test.
What a passkey changes, and what it leaves to the application
A passkey is a discoverable WebAuthn credential. The authenticator controls the private key; the relying party stores the public key and verifies signed responses. WebAuthn binds a credential to a relying-party identifier (RP ID), and the application checks the origin and fresh challenge returned in the ceremony. Correct verification provides the phishing-resistant property buyers expect, as OWASP explains. NIST describes phishing resistance in terms of binding an authenticator output to a verifier or protected channel in SP 800-63B.
The protocol does not decide whether a logged-in user may add a new credential, whether a help desk may reset the account, whether a session survives credential removal, or whether a newly authenticated account can reach another tenant's data. Those are application and operating decisions. OWASP names compromised sessions, insecure recovery and incorrect server-side account association as ways an otherwise sound passkey deployment can fail.
That distinction shapes procurement. A browser demonstration showing a working biometric prompt is useful product testing. A penetration test needs to show why the server accepts one ceremony and rejects an unauthorized variation, then follow the identity into credential management and high-value application actions. The tester should use owned test accounts and synthetic records. Your team should supply the intended policy so a rejection can be judged against an actual requirement rather than a generic checklist.
Figure 1: Follow registration, ceremony, credential changes, recovery and session authority. Stingrai synthesis. Sources: W3C WebAuthn, OWASP passkey guidance and NIST SP 800-63B.
The buyer's WebAuthn test matrix
Put the following rows into the statement of work. For each row, identify the expected result, the approved negative test, the environment, and the report artifact. The table gives test objectives, not instructions to attack a third-party service.
Boundary | Allowed proof to request | Denied proof to request | Evidence in the report |
|---|---|---|---|
Account-to-credential registration | A recently authenticated user adds a passkey to the intended test account | A stale or unrelated session cannot attach one to another account | Redacted ceremony trace, account association and server decision |
Challenge and ceremony type | Registration and login each consume their own fresh challenge once | An expired, reused or wrong-purpose challenge is rejected | Challenge lifecycle and rejection reason without exposing secrets |
RP ID and origin | The configured site origin works under its intended RP ID | An unapproved origin or RP ID combination is rejected | Origin policy, expected RP ID and server-side decision |
User presence and verification | The required UP and UV policy is enforced | A response lacking required UV does not gain high-assurance access | Policy setting, returned flags and access outcome |
Credential identity | Credential ID and user handle resolve to one server-side account | A credential cannot be assigned to a different selected account | Synthetic account matrix and account-resolution result |
Credential management | A user can name, add and revoke authorized credentials | A long-lived session cannot silently add or remove a strong credential | Reauthentication, notification, event log and revocation proof |
Recovery and fallback | The approved recovery route restores only the intended account | A weaker fallback cannot silently bypass the stated policy | Recovery approval trail and post-recovery session result |
Session and authorization | Login creates a fresh session with the correct role and tenant | An old session or another tenant's record is not accepted because login succeeded | Before/after session state and high-value authorization check |
The first five rows derive from the OWASP registration and authentication verification guidance. The last three bring the application lifecycle into scope. The purpose is to connect a protocol decision to an account decision: a report that stops at a green WebAuthn assertion misses the business risk that motivated the assessment.
Registration: whose account receives the new key?
Registration is a sensitive account change. The test should start with the application's new-account and existing-account flows, because they establish authority differently. For an existing account, OWASP recommends recent reauthentication before adding a passkey. For a new account, the registration challenge must be bound to the verified creation transaction, not to an account identifier supplied by the browser.
Ask for a pair of synthetic accounts, one authorized to enroll and one that must not be affected. The tester should inspect how the server binds the challenge to ceremony type, account, session, expected RP ID and origin policy. A valid-looking response must not be able to move a credential across those boundaries. The final artifact is not a screen recording of a prompt; it is evidence that the server stored the credential under the right account only after every required check passed.
The account owner should also specify how a user handle is generated and treated. OWASP recommends a stable, opaque handle that does not disclose a username or email address, and says it must not be reassigned to another account. A buyer can ask whether a migration, account merge or administrative workflow changes that association. That is particularly important for SaaS products with tenant moves, employee rehires or identity consolidation.
Authentication: does the server validate the entire response?
The WebAuthn library can validate cryptography, but the application must supply the expected account, origin, RP ID and verification policy. OWASP's authentication checklist covers the assertion type, unused challenge, exact allowed origin, RP ID hash, credential ID, signature, UP/UV flags and user handle. Ask the tester to document which checks are enforced by the library, which are application configuration, and what happens when a check fails.
An RP ID that spans unrelated subdomains increases the authority of every origin allowed to use it. OWASP advises choosing the narrowest stable domain and maintaining an explicit origin allowlist. If the product uses a web site, native app and embedded experience, write each expected origin into the SOW. Do not accept an answer such as “all company domains” without the exact host and platform associations. A failure in an intentionally unsupported origin should be a recorded deny result, not a test error silently dropped from the report.
User presence and user verification mean different things. UP records user interaction; UV records local verification such as a PIN or biometric. OWASP says a relying party must request and verify UV when the policy relies on that property. Include a test account with an explicit UV requirement and another, only if the business permits it, for a lower assurance flow. The report should show the policy decision, not merely the authenticator's advertised capability.
Credential lifecycle, fallback and recovery
Most procurement briefs devote pages to login and one sentence to recovery. In a passwordless rollout, credential management is often the easiest place to make a product unsafe. OWASP recommends recent reauthentication before adding or removing a passkey, changing recovery methods, or disabling the last strong authenticator. It also recommends prompt server-side revocation and a trusted-channel notification when a passkey changes.
The test should therefore include an account with more than one credential, an account with one credential, and a documented recovery route. Ask the tester to show that a removed credential stops working at the server, that an existing session cannot quietly enroll a new credential after its authority should have expired, and that a user cannot be stranded or downgraded by the “last passkey” path. Account recovery needs its own approval, logging and notification evidence. For high-risk accounts, an email or SMS fallback should not silently undo a stronger authentication policy, consistent with OWASP's recovery guidance.
Passkeys may be synced or device-bound. The buyer should state which authenticator types are allowed and why. A passkey is not automatically inappropriate because it is synced, and attestation is not a universal proof of ongoing device integrity. NIST's syncable-authenticator guidance and OWASP's attestation discussion support a policy based on the required assurance and deployment context. If the enterprise requires a managed or device-bound authenticator for a privileged role, the SOW should test that specific policy and its exception route.
Do not confuse a technical recovery test with a help-desk social-engineering exercise. The former checks the application's account and session behavior using owned test identities. The latter asks whether staff can be persuaded to move factors or bypass identity proofing. A buyer who needs both should scope both explicitly. Our account-recovery red-team guide covers the human workflow; the enterprise identity matrix covers federation and provisioning around it.
The session after a passkey login still needs a test
A passed ceremony should create a session for the correct account and no other. The tester should compare the session before and after authentication, check whether the application rotates its identifier, and check what happens to active sessions when a passkey is removed or the account is recovered. OWASP recommends creating the authenticated session only after all required assertion checks pass. It does not mean every existing session will automatically disappear when the credential changes; the product must define and implement the desired policy.
For a multi-tenant product, add at least one post-login business workflow to the assessment. A user who authenticated with the right credential can still be mapped to the wrong organization or allowed to call an API outside their role. The API authorization test matrix gives a more detailed way to select those workflows. In this passkey engagement, the purpose of the post-login check is narrower: prove that the new authentication route creates exactly the session and application authority intended.
What to provide the tester before kickoff
A focused test can be thorough without asking for a production-wide sweep. Provide the following input, and mark every item that needs a synthetic substitute:
RP and origin inventory. List production and staging hostnames, mobile app associations, expected RP IDs, embedded contexts and any planned migration. The tester needs to know which origin combinations should pass.
Account-state map. Include new, established, privileged, suspended and recovered synthetic accounts. Add separate tenants if the application is multi-tenant.
Credential policy. State whether platform, roaming, synced and device-bound credentials are supported; when UV or attestation is required; and how exceptions are approved.
Recovery map. List every fallback path, its owner, approval step, notification, delay and session effect. Include employee and customer support paths where relevant.
Test environment and rules. Give approved URLs, test window, rate limits, monitoring contact and clear exclusions. Use test accounts with synthetic records rather than live personal data.
Acceptance question. State what must be proven before launch, such as “a removed credential cannot authenticate” or “an account in Tenant A cannot become Tenant B after a new passkey enrollment.”
The quote should identify the number of applications, relying parties, origins, account types, authenticators and recovery branches. “Test passwordless authentication” by itself is not a bounded scope. Ask what the vendor will do when browser or authenticator behavior prevents a planned negative test, and whether the report will mark it untested rather than quietly treat it as passed. That question makes proposals comparable and prevents a false sense of coverage.
Report acceptance: what a useful finding and a useful clean result look like
A credible report names the policy and expected result for each test, the actual server behavior, the synthetic identity used, and the risk if the gap is exploited. It should distinguish a protocol defect from an account-workflow defect, and it should not publish private keys, full credential responses or session identifiers. The evidence can show redacted response fields, decisions, timestamps, affected endpoints and the tester's reproduction under authorized conditions.
For a clean result, ask for the negative tests and their denial evidence. “No critical findings” is not a substitute for a coverage statement. The matrix should mark each row as passed, failed, blocked, excluded or not applicable, with a reason. Ask for a retest of remediated findings and a short list of residual decisions the product owner still owns. A passkey rollout can be safe at the protocol layer yet still need an explicit decision about fallback, sessions or device assurance.
One-time testing before a major rollout is sensible when the identity architecture is new. Repeat the relevant part after an RP ID or origin change, a new mobile association, a recovery redesign, an authenticator policy change or an account migration. Those are change-driven recommendations based on the boundaries above, not a fixed interval imposed by W3C or OWASP.
Where Stingrai fits
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
For a passkey launch, the human-led scope can pair server-side ceremony testing with account lifecycle and post-login authorization checks across the actual roles and tenants. Stingrai's testers deliver findings with reproducible proof and remediation guidance, then retest fixes. Buyers can commission a one-time assessment before release or fit the application into a continuous program as its identity flows change. The web application penetration testing service and Get a Quote page are the right starting points for a tailored scope.
Frequently Asked Questions
What should a passkey penetration test cover?
It should cover registration, server-side WebAuthn verification, credential-to-account binding, credential changes, recovery, fallback and the session created after login. The buyer should ask for both allowed and denied evidence against the application's stated policy.
Is a working passkey login enough to show the rollout is secure?
No. A working login shows one allowed ceremony. It does not prove that a wrong origin is rejected, that another account cannot receive the credential, that recovery cannot bypass the policy, or that the resulting session has the right application permissions.
Must every passkey require attestation or be device-bound?
No. The authenticator policy depends on the application's assurance needs. The buyer should specify where device-bound credentials or attestation are required, and the tester should verify those rules and their exception paths rather than assume one policy fits every account.
Why test account recovery if passkeys are phishing-resistant?
Recovery can replace a lost authenticator or create a new route into the account. If a weaker fallback can silently override the intended passkey policy, the strength of the normal login ceremony does not protect that recovery path.
Can automated scanning replace a human-led WebAuthn assessment?
Automated checks can help exercise known ceremony conditions, but the buyer still needs judgment about account association, recovery, tenant roles and business impact. The report should explain which decisions were verified manually and which were assisted by automation.
When should an enterprise retest its passkey deployment?
Retest the affected boundaries after a change to the RP ID, allowed origins, mobile associations, recovery policy, credential-management flow or account migration. The trigger is a change in authority or account state, not a universal interval set by the WebAuthn specification.
Related reading
References
Talk to Stingrai
Need a passkey rollout assessment that covers the server ceremony and the account behind it? Get a Quote or book a free discovery call to scope the roles, origins, recovery branches and report evidence.
