A cognitive function test is an authentication step that depends on memory, reasoning, or problem solving, such as recalling a password or solving a challenge. Under WCAG 2.2, these tasks cannot be required in the authentication flow unless an accessible alternative is available, because they can exclude many users.
What a Cognitive Function Test Is in Authentication
A cognitive function test is an authentication step that asks a person to rely on memory, reasoning, or problem solving. Common examples include recalling a secret from memory or solving a challenge before access is granted.
These steps are meant to prove that the user can complete a mental task, but they are fragile as a security factor because they often depend on human recall rather than a stable authenticator. In practice, they can also create usability barriers when the task is hard, time-sensitive, or inaccessible.
Why This Pattern Appears in Sign-In Flows
Teams sometimes use cognitive steps because they are simple to add, familiar to users, and appear to slow down automated abuse. A password prompt, security question, puzzle, or one-time memory challenge can all sit in this category when the user must think rather than present a dedicated device or token.
The weakness is that “easy to deploy” does not mean “good authentication design.” If the step depends on recall, the security experience is often shaped more by memory quality than by assurance strength. That makes the pattern especially sensitive to password reuse, forgotten answers, account recovery pressure, and users trying to work around the prompt.
Accessibility and WCAG 2.2 Implications
Under WCAG 2.2, cognitive tests cannot be a required path through authentication unless an accessible alternative is also available. The core issue is not only whether the challenge is annoying, but whether it excludes users who cannot reliably solve, remember, or process the task in the moment.
This is why WCAG 2.2 matters for sign-in design, and why accessibility guidance treats memory-based authentication steps differently from ordinary friction in the user journey. For related authentication design principles, NIST SP 800-63 Digital Identity Guidelines is the stronger reference for how assurance should be built around authenticators rather than recall-based hurdles.
Design Trade-offs and Safer Alternatives
A cognitive function test can reduce some low-effort abuse, but it rarely scales well as a primary control. It is vulnerable to user error, coaching, guessing, and inconsistent difficulty, and it tends to perform poorly when used as the main proof of identity.
Safer authentication patterns usually shift the burden away from memory and toward stronger factors such as cryptographic authenticators, device-bound credentials, or well-designed recovery paths. Where a cognitive step is still used, it should be treated as a supplementary check, not the only way a legitimate user can get through the gate. For broader control context, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog is useful because it distinguishes authentication control design from ad hoc friction.
Risk and Threat Considerations
Cognitive function tests create both security and accessibility risk because they depend on human memory and reasoning under real-world conditions. If they are the only authentication path, legitimate users can be locked out, while attackers may still bypass them through guessing, social engineering, or credential reuse.
Failure mechanism: The mechanism fails when access depends on a task that users cannot reliably complete, or when the task is weak enough to be guessed, trained around, or reused across accounts. That produces both false rejects for legitimate users and weak assurance against abuse.
Impact: The result can be account access failure, higher help-desk load, insecure recovery workflows, and exclusion of users who need an accessible alternative. In regulated or public-facing environments, the control can also create compliance and usability problems that outweigh its intended security benefit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines authentication assurance and accessible sign-in design for recall-based steps. |
| Recommendation — Prefer authenticators and accessible alternatives over memory-based authentication challenges. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers user authentication design where cognitive steps may be used as part of access control. |
| IA-5 — Authenticator Management | Addresses lifecycle and handling of authenticators that should replace fragile recall-based checks. | |
| Recommendation — Use strong user authentication methods instead of relying on cognitive challenges alone. Manage authenticators so access does not depend on reusable memory-based prompts. | ||
| OWASP ASVS | V6 — Authentication | Authentication verification requirements include resilient login design and alternative paths. |
| Recommendation — Verify authentication flows include accessible, robust alternatives to cognitive challenges. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control policies govern how authentication steps are permitted and enforced. |
| Recommendation — Define access control rules that avoid mandatory memory-based authentication barriers. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account access design and recovery processes are directly affected by weak authentication hurdles. |
| Recommendation — Reduce account friction by aligning authentication and recovery with robust account management. | ||
Practitioner Guidance
Why practitioners should care: Cognitive tests are best treated as a design smell when they are required for access, not as a durable authentication foundation. If the flow cannot be completed without memory or problem solving, the product is probably relying on the wrong kind of proof.
Governance implication: Authentication policy should require a non-cognitive fallback that preserves access without forcing a memory challenge. That keeps assurance design aligned with usability, accessibility, and operational support expectations.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
