Acceptance Criteria for a Login Page: Complete Examples
By SayCraft Team · 2026-08-17 · 11 min read
Login acceptance criteria should cover success, empty or malformed input, invalid credentials, loading, duplicate submission, safe redirect, session expiry, password recovery, keyboard focus, and readable error feedback. They should describe observable behavior without deciding the product's identity architecture. Use a generic authentication response where account existence must not be exposed, and add throttling, lockout, MFA, SSO, or passkey criteria only when the responsible owner adopts those policies. The Given/When/Then set and risk-to-test map below are directly adjustable starting points; they are not a penetration test, threat model, security review, or compliance certificate.
Complete Given/When/Then criteria
Given the sign-in form is ready When a user submits valid credentials Then the system creates the intended session And redirects to the safe destination agreed for that role Given required fields are empty or malformed When the user submits Then each invalid field has clear correction guidance And keyboard focus moves to the first error or an associated error summary Given credentials are invalid, the account is unknown, or its state blocks login When the user submits Then the visible response uses a generic authentication error And does not reveal which credential or account condition failed Given a sign-in request is processing When the user activates submit again Then duplicate requests are prevented And a visible, announced loading state remains until success or failure Given a user requests password recovery When they submit an identifier Then the visible response does not reveal whether an account exists And any issued recovery link follows the product's approved expiry and reuse policy Given an authenticated session expires When the user opens a protected destination Then the system requests authentication And returns only to a validated destination after success
Criteria-to-test mapping
| Risk | Acceptance evidence |
|---|---|
| Account enumeration | Compare visible responses and timing behavior for valid and unknown identifiers under the approved implementation. |
| Repeated submission | Activate submit repeatedly and verify one authoritative authentication attempt/result is handled by the client flow. |
| Keyboard and errors | Complete validation and recovery without a pointer; verify labels, focus, correction text, and announcements. |
| Unsafe redirect | Submit valid and manipulated return destinations; only approved local destinations are used. |
| Rate limiting or lockout | Test the throttling policy chosen by the security owner without treating this template as the policy source. |
Conditional criteria, not universal decisions
Throttling, lockout, MFA, passkeys, SSO, remembered devices, and session duration depend on the product's threat model and identity architecture. If the product adopts one, add criteria for enrollment, challenge, recovery, cancellation, fallback, and support. Do not silently invent the policy in a UI ticket.
Connect the criteria to the relevant user story, turn them into software test cases, and record behavior and quality conditions in the requirements pair.
Sources used for this guide
Turn the document into something testable
Use the criteria to build and review the complete sign-in experience, including error and recovery states. Before real accounts are used, keep identity architecture and security review as separate owners.
Frequently asked questions
What are acceptance criteria for a login page?
They are observable conditions covering valid sign-in, validation, invalid credentials, loading, duplicate submission, session and redirect behavior, account recovery, accessibility, and security policies selected for the product.
Should login errors say whether an account exists?
OWASP recommends generic authentication responses so externally visible messages do not reveal whether the username, email, password, or account state caused the failure.