A.8.5
Secure authentication
Technological controlsCheckpoints 5Evidence 6Cases 5
Control objective
This control requires authentication technologies and procedures to be applied in proportion to the sensitivity and risk of the information and systems being accessed, so that the claimed identity of a user/entity is verified before access is granted. By setting authentication strength to match asset classification and risk, it reduces the risk of unauthorized access through credential theft, guessing, or reuse.
Key checkpoints
- Are authentication methods (knowledge/possession/biometric based) applied differentially according to the sensitivity and risk of the information/system being accessed?
- Is multi-factor authentication (MFA) applied to high-risk access such as privileged accounts, remote access, and access to critical systems?
- Are repeated failures controlled through delays, attempt limits, or suitable lockout, with limited information in error messages? Is CAPTCHA used only as a supplement to these controls?
- Are storage protection and secure transport appropriate to credential type, including password-verification hashing and encryption/access control for recoverable secrets?
- Are secure log-on procedures (input masking, session timeout, access warning banner) configured, and are authentication events logged and monitored?
Implementation guidance
- Select authentication factors based on asset classification and risk assessment results, applying multi-factor authentication for high-risk access.
- Mask password entry by default; a user-controlled temporary reveal option may be offered with shoulder-surfing risk in view. Protect transport with TLS or an equivalent secure channel and prohibit plaintext transmission.
- Store verifier-held passwords using a purpose-built password hashing scheme with unique salts and an appropriate work factor. A general-purpose hash alone is insufficient; apply separate encryption/access controls to recoverable service secrets and private keys.
- Apply lockout/delay/alerts for repeated login failures, and do not indicate in error messages whether the ID or the password was wrong.
- Terminate idle sessions automatically, require re-authentication for sensitive operations, and consider adaptive authentication based on context such as location, device, and behavior.
- Consider phishing- and replay-resistant authentication for high-risk access. For FIDO2 or certificate-based methods, verify binding to the verifier/service identity in the actual configuration; the presence of a certificate alone does not establish phishing resistance (linked to A.5.17).
Evidence
- Authentication policy/standard defining authentication methods per classification/risk
- MFA configuration screens for privileged/remote/critical access
- Account lockout/login attempt limit configuration screens
- Evidence of password hashing scheme/salts/work factor, recoverable-secret protection, and transport encryption settings
- Access warning banner and session timeout configuration screens
- Authentication success/failure logs and abnormal authentication monitoring/alert records
Nonconformity examples
- The administrator console/privileged accounts are accessible with a single password and no multi-factor authentication is applied.
- Login error messages specifically reveal whether the ID or the password was wrong.
- There is no account lockout/attempt limit, so unlimited login attempts (brute force) are possible.
- Credentials are transmitted in cleartext (HTTP) or stored in cleartext or with weak hashes.
- Multiple users share a single privileged account, so individual authentication is not performed.