Secure authentication
Purpose
Make sure users and entities are securely authenticated before access to systems, applications and services.
How to meet this control
In short: Implement secure authentication technologies and procedures.
- Step 01Centralise authentication on a single identity provider (Entra ID, Okta, Google Workspace) and connect applications via SSO so credentials are not scattered
- Step 02Enforce MFA for all users, prioritising phishing-resistant methods such as passkeys, FIDO2 keys or authenticator app number matching over SMS
- Step 03Replace shared passwords with conditional access policies that consider device, location and risk signals
- Step 04Configure account lockout or risk-based throttling and CAPTCHA to defeat brute-force and password-spray attacks
- Step 05Disable legacy authentication protocols that bypass MFA, such as basic auth and IMAP or POP
- Step 06Set session timeouts and re-authentication for sensitive applications and log all sign-in attempts to the SIEM
Tip: Enforce MFA, especially on email, admin, and remote access.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Pick an authentication method matched to the sensitivity of the information
- ›Use multi-factor authentication for critical systems
- ›Provide alternatives to passwords where strong assurance is needed, such as certificates or tokens
- ›Have a fallback method for biometrics and invalidate biometric data if compromised
- ›Design log-on to reveal nothing useful until completed and give no helpful error hints
- ›Protect against brute force with CAPTCHA, lockouts or forced resets, and log attempts
- ›Alert users and admins on suspected breaches and never display or transmit passwords in clear text
- ›Terminate inactive sessions and limit connection times for high-risk applications
Audit evidence to keep
- - MFA enforcement screenshot from the identity provider showing coverage
- - Conditional access or sign-in risk policy configuration
- - Report confirming legacy or basic authentication is blocked
- - Sign-in logs showing failed attempts and lockout or throttling in action
- - Authentication policy specifying methods and session timeout rules
Common mistakes
- - Writing a policy but not operating the process
- - Keeping evidence in personal folders where auditors cannot trace it
- - Letting exceptions stay open with no owner or expiry date
Owner, cadence, and proof
Assign one accountable owner for A.8.5. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.