We have all seen the headlines. A massive data breach occurs, and it turns out the “hacker” didn’t use some sophisticated zero-day exploit or crack a complex encryption algorithm. They just guessed the password “Password123” or bought a stolen credential on the dark web.
Authentication is the front door to your organisation’s data. If you leave the key under the mat, it doesn’t matter how expensive your alarm system is. This is why ISO 27001:2022 Annex A 8.5 exists.
In the 2022 update of the standard, “Secure Authentication” replaces and consolidates several older controls regarding passwords. It acknowledges a simple truth: passwords alone are no longer enough. Here is how to implement this control effectively without frustrating your users or breaking the bank.
Table of contents
What is Annex A 8.5?
Annex A 8.5 is a technological control that requires organisations to implement secure authentication technologies and procedures. The goal is simple: ensure that a person (or entity) is who they claim to be before granting access to your systems.
The standard moves away from prescriptive rules like “change passwords every 90 days” (which is actually bad advice now) and moves towards a risk-based approach. It asks you to match the strength of the authentication to the sensitivity of the information.
Step 1: Define Your Policy
Before you start rolling out technology, you need to set the rules. You need a Topic-Specific Policy on Access Control (linked to Annex A 5.15) that specifically addresses authentication.
Your policy should answer questions like:
- Where is Multi-Factor Authentication (MFA) required? (Hint: Everywhere possible, but definitely for remote access and admin accounts).
- What are the password requirements? (Length is better than complexity. “Horse-Battery-Staple” is harder to crack than “Tr0ub4dor&3”).
- How do we handle forgotten credentials?
If you need a head start on drafting this, Hightable.io offers robust ISO 27001 toolkits that include pre-written Access Control and Authentication policies aligned with the 2022 standard.
Step 2: Implement Multi-Factor Authentication (MFA)
If you take one thing away from this guide, let it be this: Enable MFA.
The guidance for Annex A 8.5 heavily implies that single-factor authentication (just a password) is rarely sufficient for accessing sensitive data. You should verify identity using at least two of the three classic factors:
- Something you know: A password or PIN.
- Something you have: A smartphone app (like Microsoft Authenticator), a hardware token (YubiKey), or a smart card.
- Something you are: Biometrics (FaceID, fingerprint).
Start by enabling MFA on your “crown jewels”—your email system (Microsoft 365/Google Workspace), your VPN, and your cloud infrastructure (AWS/Azure).
Step 3: Fix Your Password Rules
For systems where MFA isn’t possible, or as the “first factor,” you still need passwords. But the old rules have changed. Modern best practice (aligned with NIST and ISO) suggests:
- Stop forced rotation: Don’t make users change passwords every 90 days. It just encourages them to write them down or pick “PasswordSpring2024”. Only change passwords if there is a suspicion of compromise.
- Prioritise length: A 14-character sentence is much stronger than an 8-character complex mess.
- Ban common passwords: Configure your systems to reject common passwords like “Companyname123”.
- Use Password Managers: Encourage or provide enterprise password managers so staff don’t have to remember 50 different complex codes.
Step 4: Secure the Log-On Process
Annex A 8.5 also cares about how the login happens. You need to ensure the process itself doesn’t leak information.
Generic Error Messages: When a login fails, the system should say “Invalid Username or Password,” not “Invalid Password.” Telling an attacker that the Username is correct is giving them half the puzzle.
Masking: Passwords should never appear in clear text on the screen. They should be masked with asterisks (*).
Anti-Brute Force: Implement lockouts or throttling. If someone tries to guess a password 10 times in one minute, the account should lock, or the delay between attempts should increase.
Step 5: Don’t Forget Non-Human Accounts
Your servers and applications authenticate too. Annex A 8.5 applies to “Service Accounts” and API keys.
Ensure that hard-coded passwords aren’t sitting in plain text in your software code (see Annex A 8.4). Use managed identities or key vaults to handle these credentials securely.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls to Avoid
- SMS for MFA: While SMS is better than nothing, it is vulnerable to “SIM Swapping.” Use an Authenticator App where possible.
- The “Break Glass” Account: If your MFA system goes down, how do you get in? Ensure you have a highly secured emergency admin account that bypasses MFA, stored in a physical safe, for absolute emergencies.
- Ignoring Legacy Systems: “The old finance system doesn’t support MFA” is a risk, not an excuse. If you can’t secure the app, isolate it on the network.
What Will the Auditor Look For?
When the audit comes, be prepared to show:
- Policy: Your documented rules for authentication.
- Configuration Evidence: Screenshots showing MFA is “Enforced” for users.
- Onboarding Records: How do you verify a new employee is who they say they are before giving them a password?
- Logs: Evidence that you are monitoring for failed login attempts (linked to Annex A 8.16).
Conclusion
Implementing ISO 27001 Annex A 8.5 is about closing the front door. By moving beyond simple passwords and adopting MFA and modern identity practices, you significantly raise the bar for attackers. It’s one of the highest-value controls in the entire standard—get this right, and you eliminate the vast majority of common cyber threats.
If you need help structuring your policies or understanding the nuances of the new control, resources like Hightable.io provide excellent guidance and templates to keep your implementation on track.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
