Acceptance criteria examples

Acceptance criteria for login and registration: examples and checklist

Authentication flows look simple until a team needs to define validation, security, privacy, recovery, and session behavior. These examples give product, engineering, and QA teams a shared starting point.

What should login and registration criteria cover?

Good authentication criteria define the happy path and the rules around it: required fields, error messages, duplicate accounts, verification, forgotten passwords, rate limits, and what happens after a user signs in. They should describe observable behavior, not prescribe an implementation.

Registration acceptance criteria example

Feature: Create an account

Scenario: Register with valid details
Given a visitor does not have an account
When they submit a valid name, email address, and password
Then an account is created
And the visitor is asked to verify their email address

Scenario: Prevent duplicate accounts
Given an account already exists for an email address
When a visitor tries to register with that address
Then the system explains that an account already exists
And it offers a way to sign in or reset the password

Scenario: Validate the password
Given a visitor is registering an account
When their password does not meet the displayed requirements
Then the account is not created
And the system explains which requirement is not met

Login acceptance criteria example

Feature: Sign in to an account

Scenario: Sign in with valid credentials
Given a registered user has a verified account
When they enter their valid email address and password
Then they are signed in
And they are taken to their intended page or dashboard

Scenario: Reject invalid credentials without exposing account details
Given a visitor enters an incorrect email address or password
When they submit the login form
Then they remain signed out
And the system shows a generic invalid credentials message

Scenario: Lock a temporarily blocked account
Given an account has reached the configured number of failed sign-in attempts
When another sign-in attempt is made
Then the account cannot be signed in to until the lock period ends
And the user is told how to recover access

Password reset and email verification

Feature: Recover account access

Scenario: Request a password reset
Given a visitor has forgotten their password
When they submit an email address
Then the system shows the same confirmation message whether or not the address is registered
And a registered account receives a single-use reset link that expires

Scenario: Use an expired reset link
Given a password reset link has expired or has already been used
When the visitor opens it
Then the system does not allow a password change
And it offers a way to request a new link

Scenario: Verify an email address
Given a newly registered user receives a verification link
When they open the valid link before it expires
Then their email address is marked as verified
And they can access features that require a verified account

Authentication review checklist

• Are required fields and valid formats clear?
• Can the UI handle duplicate email addresses without revealing unnecessary account information?
• Do error messages tell users what to do next without exposing whether an account exists?
• Are verification and reset links single-use and time-limited?
• Are failed sign-in attempts and account recovery rules defined?
• Does the team know where a user goes after successful sign-in or sign-out?
• Can QA test the happy path, validation paths, expired-link paths, and lockout behavior?

Adapt these examples to your product

Use the examples as a starting point, then add the rules that are specific to your product: social sign-in, multi-factor authentication, invitation-only accounts, organization membership, required consent, or regional privacy requirements. Keep each scenario focused on one outcome so it remains easy to test.