Passkeys, sessions and access rights

What does sign-in establish?

Authentication concerns identity, authorization concerns actions and session handling concerns continued access. This separation helps define an assessment.

NIST SP 800-63B-4 distinguishes phishing-resistant cryptographic authentication from manually entered one-time codes. Sign-in strength is therefore a specific question, not a complete application verdict. [1]

The other half of the question

Being signed in should not itself grant access to any invoice or administration function. OWASP retains broken access control as a distinct category in its Top 10:2025.

We recommend a small expectation matrix: role, object, permitted action and expected refusal. “Test the login” is not precise enough. [2]

A fictional test case

A service has two customer organizations, each with ordinary and administrative test roles. The agreed rule is that invoice exports remain within the relevant organization.

The result records the test roles, expected behavior, observed behavior and affected function. A finding about one export function is not expanded into an unsupported claim about the entire application.

Test the end of access

We suggest planning three state changes: logout, role change and account suspension. Define which session or function must stop working after each change.

Retests should preserve the original conditions or explain the differences. Otherwise a changed scenario may be mistaken for successful remediation.

Prepare explicit expectations

The following is our editorial checklist for a clear assessment request.

• Test identities with distinct roles
• Two test organizations for tenant-aware applications
• Approved objects and functions
• Expected behavior after logout and suspension
• Finding and retest acceptance criteria

Related reading

• Assessing dark web and leak findings
• Testing and documenting security controls