A knowledge factor is information the user is expected to remember, such as a password, PIN, or security question answer. In authentication design, it is the weakest standalone factor because it can be guessed, phished, reused, or observed, so it is usually more effective when combined with another factor.
Expanded Definition
“Something you know” is the knowledge factor in authentication: a secret that the user can recall and present on demand, such as a password, PIN, passphrase, or answer to a memorised challenge. It is distinct from possession factors, such as a device or token, and inherence factors, such as a biometric. In practice, its security depends on how difficult the secret is to guess, expose, reuse, or coerce from the user.
The key boundary is that a knowledge factor is not secure simply because it is private. A password may be long and unique, yet still fail if it is phished, captured by malware, reused across services, or stored in a weak recovery flow. Guidance is fairly consistent that knowledge factors should not stand alone for high-value access, although the exact strength requirements vary by implementation and threat model. For that reason, the term is best understood as an authentication input class rather than a guarantee of assurance.
Examples and Use Cases
Knowledge factors appear in many everyday and administrative workflows, but the security outcome depends on how they are used and protected.
- A consumer login prompt asks for a password before allowing access to an account, often with a second factor added for stronger assurance.
- A mobile banking app uses a memorised PIN for convenience, but may limit its use to local device unlock rather than full account recovery.
- An administrator uses a passphrase to unlock an encrypted vault, where the main tradeoff is between memorability and resistance to guessing.
- A support desk uses challenge questions for account recovery, which can be weaker than intended because answers are often discoverable or reusable.
- Some systems still rely on shared secrets for legacy integrations, which can be operationally simple but difficult to govern at scale.
Where knowledge factors are used in higher-risk environments, the implementation choice is usually not whether to have a secret at all, but whether the secret is paired with another factor, protected against interception, and limited in how far it can be used.
Security Implications
Misunderstanding “something you know” leads to predictable authentication failure modes. The most common are guessing, phishing, credential stuffing, reuse across services, and recovery pathways that are weaker than the primary login. Because the factor is human-memorable, it is also human-shareable, which makes coercion and accidental disclosure part of the threat model rather than edge cases.
The practical consequence is that the weakest point is often not the password policy itself, but the surrounding system: password reset, help-desk identity proofing, device prompts that reveal secrets, or monitoring that cannot distinguish legitimate recall from credential theft. A strong secret can still be defeated if the same value is accepted repeatedly without additional context or if the organisation treats memorised knowledge as sufficient proof of identity for sensitive actions.
For this reason, authentication systems should be assessed as a whole. A memorable secret may be acceptable for low-risk access, but it becomes materially weaker when it is the only barrier to privileged actions, financial activity, or recovery of another factor.
Domain and Governance Relevance
In identity and access governance, “something you know” matters because it defines a class of authenticators that is easy to deploy but difficult to trust on its own. The governance question is not merely whether a password exists, but what assurance level the organisation assigns to that secret and what consequences follow if it is compromised.
This becomes more important when knowledge factors are used for recovery or step-up verification. A recovery secret that is easier to obtain than the account itself can undo stronger controls, while an over-reliance on memorised secrets can create a false sense of assurance in access reviews and policy statements. Good governance therefore focuses on where knowledge factors are permitted, where they must be paired with another factor, and which account types are excluded from password-only access.
For teams managing service access, secrets tied to human use cases should also be distinguished from machine credentials. That boundary matters because human-recalled secrets, shared administrative passwords, and non-human credentials behave differently across lifecycle, ownership, and revocation.
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, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authentication Assurance Level | Defines assurance expectations for knowledge-based authenticators. |
| Recommendation — Map password use to the required AAL and avoid using memorised secrets alone where higher assurance is needed. | ||
| CIS Controls v8 | 6 — Access Control Management | Covers account access, authenticator handling, and privileged access restrictions. |
| Recommendation — Enforce unique, managed credentials and remove shared or weak knowledge-factor access paths. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Addresses authentication design and access assurance for user accounts. |
| PR.AC — Access Control | Applies where memorised secrets gate access to systems or privileged actions. | |
| Recommendation — Set authentication policy so knowledge factors are only one part of the access control design. Limit the blast radius of password compromise by enforcing least privilege and step-up checks. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access to System Components | Requires strong authentication controls around account access and credentials. |
| Recommendation — Use PCI DSS authentication requirements to harden any environment that accepts password-based access. | ||
