In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.17 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 5.17 Authentication Information
ISO 27001 Annex A 5.17 requires organizations to control the allocation and management of authentication information (passwords, PINs, biometrics, or tokens) through a formal management process. This control ensures that the “secrets” used to prove an identity remain confidential and are handled securely throughout their entire lifecycle. The goal is to prevent unauthorized access by ensuring that authentication data is never shared, easily guessed, or left in clear text.
Core requirements for compliance include:
- Secure Allocation: You must have a process for creating and distributing initial credentials. Temporary passwords should be unique, complex, and forced to change upon first login.
- Identity Verification: Before issuing new or replacement credentials (e.g., a password reset), you must verify the identity of the requester to prevent social engineering attacks.
- Password Management Systems: Organizations should use systems that enforce strong password criteria (length and complexity) and protect stored credentials using industry-standard encryption.
- User Awareness: Personnel must be briefed on their responsibilities, such as not sharing passwords, avoiding reuse across different sites, and using a vetted Password Manager.
- MFA Implementation: While not explicitly mandated by the text of A.5.17, the 2022 standard strongly implies the use of Multi-Factor Authentication (MFA) for sensitive or remote access as a best-practice management process.
- Change Mandatory Defaults: Any default manufacturer passwords or PINs must be changed immediately upon system installation.
Audit Focus: Auditors will look for “The Credential Gap”:
- Reset Procedures: “If I call your IT helpdesk and say I’ve forgotten my password, how do they verify it’s really me before resetting it?”
- MFA Everywhere: “Show me your login screen for your email and VPN. Do they require MFA? If not, how do you justify the risk of using only single-factor authentication?”
- Password Hygiene: They may perform “desk checks” to look for written passwords (post-it notes) or ask employees how they generate and store their secrets.
Authentication Checklist (Audit Prep):
| Rule Category | Recommended Action (Do) | Prohibited Action (Don’t) | ISO 27001:2022 Control |
|---|---|---|---|
| Storage | Use a vetted Password Manager. | Write it on a Post-It note or in a file. | Annex A 5.17 |
| Sharing | Delegate access via separate IDs. | Text or email your password to a colleague. | Annex A 5.17 / 8.15 |
| Complexity | Use long Passphrases. | Use simple words like “Password123.” | Annex A 5.17 |
| Reuse | Unique credentials for every site. | Use the same password for Work and Social. | Annex A 5.17 |
| MFA | Approve only requests you triggered. | Approve random push notifications (fatigue). | Annex A 5.17 / 8.5 |
Table of contents
- What is ISO 27001 Annex A 5.17?
- Watch the ISO 27001 Annex A 5.17 Tutorial
- ISO 27001 Annex A 5.17 Podcast
- ISO 27001 Annex A 5.17 Implementation Guidance
- How to implement ISO 27001 Annex A 5.17
- User Responsibility Checklist
- ISO 27001 Access Control Policy Template
- How to comply
- How to pass an ISO 27001 Annex A 5.17 audit
- What the auditor will check
- Top 3 ISO 27001 Annex A 5.17 Mistakes People Make and How to Avoid Them
- Applicability of ISO 27001 Annex A 5.17 across different business models.
- Fast Track ISO 27001 Annex A 5.17 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.17 FAQ
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 controls and attribute values
What is ISO 27001 Annex A 5.17?
ISO 27001 Annex A 5.17 is about authentication information which is about providing a way for people to prove they are who they say there when accessing systems or information.
ISO 27001 Annex A 5.17 Authentication Information is an ISO 27001 control that requires an organisation to mange the full life cycle of authentication information.
Authentication information is the information that is used to gain access to systems and resources.
ISO 27001 Annex A 5.17 wants this to be managed. Which seems sensible.
ISO 27001 Annex A 5.17 Purpose
The purpose of ISO 27001 Annex A 5.17 is a preventive control that ensures proper entity authentication and prevents failures of authentication processes.
ISO 27001 Annex A 5.17 Definition
The ISO 27001 standard defines ISO 27001 Annex A 5.17 as:
Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information.
ISO 27001:2022 Annex A 5.17 Authentication Information
Watch the ISO 27001 Annex A 5.17 Tutorial
In the video ISO 27001 Authentication Information Explained – ISO27001:2022 Annex A 5.17 show you how to implement it and how to pass the audit.
ISO 27001 Annex A 5.17 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.17 Authentication Information. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 5.17 Implementation Guidance
Allocating the authentication information
When it comes to creating the passwords and pins that will be used you may want to consider generating them automatically. This can make the process more efficient. To consider is
- Creating temporary authentication information for first time use
- Making sure the temporary authentication is hard to guess and unique for each person
- That it must be changed on first use.
We do not want to give access to any old Tom, Dick or Harry so you will have a way to check and verify the identity of any person making the request and any person being given new, updated or replacement credentials. They may, or may not, be the same person.
When we send authentication information to people we are going to do it in a secure way. We are not going to email it or send it in clear text where possible.
The standard wants a step where the user acknowledges that they have received this information.
We keep a record of what we have allocated and what we have managed and we protect that record.
Lastly if a vendor or supplier provides for default passwords, pins and authentication information we change that immediately.
What is the user responsible for?
Users do have some responsibility. They are not to share their passwords or secret authentication information.
If there is a compromise or a leak then the information and credentials are change immediately that you are notified.
Strong passwords, where passwords are used are implemented. This means passwords should not be easy to guess, or be based on something someone could guess or find out. The example is not to use dictionary words or combinations of. This is actually bullshit as the use of dictionary words to make up a phrase would be an ideal password but the standard thinks it knows better.
Passwords have a minimum length according to the standard which is pure genius as any word has a minimum length. It gives no guidance so choose wisely.
Ideally we do not reuse password across different systems.
Contracts of employment include the obligation to follow these rules.
Guidance on a password management system
General guidance on password management systems, which ever you choose, would be
- Users are allowed to select and change their own passwords
- They enforce strong passwords according to best practice
- They force users to change passwords at first use
- They force password changes as required such as after a security incident
- Ideally they prevent re-use of previous passwords
- They prevent the use of common passwords
- Where possible they take account of compromised accounts and passwords and prevent their use
- They do not display passwords on the screen when being entered
- They do not store or send passwords in clear text
- Passwords should be encrypted
Exceptions
There are many ways in which the standard is still old fashioned and a little out of date. You see this come up a lot where it tells you what to do and then says, but in the real world we know you cannot, so do not.
Some exceptions would be that clearly, other ways to authenticate other than passwords are acceptable. Consider tokens, card, biometrics.
Contrary to the standard there is an argument to not frequently change passwords. It does acknowledge this as a scenario which is good. It is about finding the balance for you based on risk and business need and being able to argue that with an auditor.
How to implement ISO 27001 Annex A 5.17
Implementing ISO 27001 Annex A 5.17 requires a transition from simple password management to a comprehensive lifecycle governance of all authentication secrets. By formalising how secrets are generated, stored, and revoked, organisations mitigate the risk of credential-based breaches and unauthorised system access. This action-orientated guide provides the technical steps necessary to build an audit-compliant authentication framework that satisfies the 2022 standard requirements.
1. Formalise the Topic-Specific Policy on Authentication Information
Establish a documented policy that defines the organisation’s technical and procedural requirements for managing secrets. This action results in a consistent governance layer that dictates how users and administrators interact with authentication systems.
- Define mandatory complexity requirements, including length, character types, and entropy standards for all passwords.
- Prohibit the sharing of credentials and mandate the use of individual, non-generic identities for all system access.
- Document the organisational stance on biometric data, hardware security keys, and digital certificates.
2. Provision Multi-Factor Authentication (MFA) Across the Infrastructure
Enforce MFA as a technical prerequisite for all access to organisational assets, prioritising privileged accounts and remote access. This results in a multi-layered defence that protects against credential stuffing and brute-force attacks.
- Implement hardware-based tokens (e.g. FIDO2) or time-based one-time passwords (TOTP) rather than vulnerable SMS-based verification.
- Configure conditional access policies that require MFA based on risk factors such as location, device health, or unusual login patterns.
- Ensure that MFA is enforced for all cloud service providers (SaaS) and internal administrative consoles.
3. Formalise Procedures for Changing Default Vendor Secrets
Establish a mandatory technical protocol for the immediate modification of all default vendor passwords and authentication settings upon deployment. This action eliminates one of the most common entry points for external attackers.
- Document a “Standard Operating Procedure” (SOP) that requires default password changes as part of the asset commissioning checklist.
- Disable or rename default administrative accounts (e.g. “admin” or “root”) to increase the difficulty of credential discovery.
- Verify that default SSH keys, API secrets, and database credentials are regenerated during the initial configuration phase.
4. Provision a Centralised Enterprise Password Manager
Deploy an encrypted password management solution to facilitate the secure creation and storage of complex secrets. This action results in a reduction of insecure practices, such as writing down passwords or storing them in unencrypted local files.
- Configure the tool to enforce the use of unique, long-form passphrases for every individual service.
- Establish “Secure Vaults” with granular access controls for sharing team-based secrets where individual accounts are not technically feasible.
- Enable administrative auditing to track secret access without exposing the actual authentication information.
5. Formalise the Revocation and Reset Lifecycle
Implement a structured process for resetting compromised credentials and revoking access for leavers or movers. This action ensures that authentication secrets do not remain valid beyond their period of necessity, preventing unauthorised post-employment access.
- Establish a 24-hour kill-switch protocol to revoke all MFA tokens and logical access upon an employee’s resignation or notice.
- Provision a secure, out-of-band method for users to reset forgotten passwords without involving insecure helpdesk verification.
- Mandate the immediate rotation of all shared secrets if a member of the authorised group leaves the organisation.
User Responsibility Checklist
| Rule | Do | Don’t |
| Storage | Use a Password Manager (e.g., 1Password). | Write it on a Post-It note. |
| Sharing | Delegate access properly (separate accounts). | Text your password to a colleague. |
| Complexity | Use Passphrases (e.g., “Correct-Horse-Battery”). | Use “Password123”. |
| Reuse | Unique password for every site. | Use the same password for Work and Facebook. |
| MFA | Approve only requests you triggered. | Approve random push notifications. |
ISO 27001 Access Control Policy Template
The ISO 27001 Access Control Policy template is pre written and ready to go. It is one of the required ISO 27001 policies that sets out the organisations approach to access control.
How to comply
To comply with ISO 27001 Annex A 5.17 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to
- Implement a process for creating, updating and removing authentication information
How to pass an ISO 27001 Annex A 5.17 audit
To pass an audit of ISO 27001 Annex A 5.17 you are going to make sure that you have followed the steps above in how to comply.
What the auditor will check
The audit is going to check a number of areas. Lets go through the most common
1. That you have not done something stupid
The auditor is going to check the rules, procedures and access control methodology and make sure you followed them. As with everything having documented evidence of anything you can is going to be your friend. So practical things like authentication information registers, encrypted passwords, approval and allocation processes that you can evidence are in operation. Work through recent hires for example and ensure the processes were followed and look for the gotchas. Is there an approval audit trail. When you log into the system that was approved does the users access match what was requested.
2. That you have rules, processes and you have followed them and have trained people
This is obvious but they are going to look that you have documented what you say you do, that you follow it and that you have trained people.
3. Documentation
They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match. Doing anything else would be a massive own goal.
Top 3 ISO 27001 Annex A 5.17 Mistakes People Make and How to Avoid Them
The top 3 Mistakes People Make For ISO 27001 Annex A 5.17 are
1. Share authentication information
There are circumstances where people know share authentication information and they do not need to. This is usually just lazy admin. The sharing of accounts where it doesn’t and should be needed.
2. Your temporary passwords are always the same
Giving first time passwords and making them unique may be a little tricky so often people rely on one password they always send out. Something like P@assw@rd. Do not do this.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability of ISO 27001 Annex A 5.17 across different business models.
| Business Type | Applicability & Interpretation | Examples of Control |
|---|---|---|
| Small Businesses |
Password Hygiene & MFA. You likely don’t have a dedicated CISO. Compliance relies on forcing Multi-Factor Authentication (MFA) everywhere and ensuring staff don’t reuse personal passwords for work. |
• Password Managers: Mandating the use of a business password manager (e.g., 1Password) to share credentials securely instead of emailing them. |
| Tech Startups |
Secrets Management. Beyond user passwords, you manage API keys and SSH tokens. Auditors check if developers are hardcoding credentials into Git repositories (a major non-conformity). |
• Environment Variables: Using tools like AWS Secrets Manager or HashiCorp Vault to inject keys at runtime, rather than storing them in code. |
| AI Companies |
Service Accounts & Data Lakes. AI training pipelines often run as “Service Accounts” with massive privileges. These non-human identities must be managed just as strictly as human users. |
• Jupyter Notebook Hygiene: Scanning notebooks to ensure API keys for model providers (e.g., OpenAI) aren’t left in the cells before committing to shared repos. |
Fast Track ISO 27001 Annex A 5.17 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 5.17 (Authentication information), the requirement is to manage the full lifecycle of authentication secrets, such as passwords, pins, tokens, and biometric data. This ensures that only verified entities can prove their identity and gain access to systems, preventing unauthorised entry and credential theft.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Standard Ownership | Rents access to authentication rules; if you cancel the subscription, your documented password standards and MFA requirements vanish. | Permanent Assets: Fully editable Word/Excel Authentication Policies that you own and control forever. | A localized “Password Policy” defining complexity, rotation, and mandatory MFA requirements for all users. |
| Security Governance | Attempts to “automate” monitoring via dashboards that cannot verify the physical security of “secret” notes or manual seed backups. | Governance-First: Provides the framework to ensure personnel handle authentication secrets (passwords, tokens) securely. | A “Secret Handling Procedure” proving employees are instructed on the secure storage and disposal of authentication info. |
| Cost Efficiency | Charges a “Seat Tax” or integration fees that scale costs as your user base and authentication methods expand. | One-Off Fee: A single payment covers your authentication governance for 10 users or 10,000. | Allocating budget to hardware security keys or biometrics rather than monthly “compliance dashboard” fees. |
| Technical Freedom | Mandates specific reporting formats that may not align with your specific SSO (Single Sign-On) or Passwordless setups. | 100% Agnostic: Procedures adapt to any tech stack—SSO, Biometrics, MFA, or hardware tokens—without limits. | The ability to evolve your authentication strategy (e.g., moving to FIDO2) without reconfiguring a rigid SaaS module. |
Summary: For Annex A 5.17, the auditor wants to see a formal management process for authentication secrets and proof that personnel are advised on proper handling. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 Annex A 5.17 FAQ
What is ISO 27001 Annex A 5.17?
ISO 27001 Annex A 5.17 is an organisational control that requires the management of authentication information throughout its lifecycle, ensuring secrets like passwords or biometrics are created, stored, and handled securely.
- Mandates the establishment of a topic-specific policy on authentication.
- Focuses on protecting the confidentiality of authentication secrets.
- Requires users to follow secure practices for handling their own credentials.
- Ensures that default vendor passwords are changed immediately upon installation.
Is Multi-Factor Authentication (MFA) mandatory for ISO 27001?
While not explicitly named “mandatory” in the standard’s text, MFA is considered a de facto requirement for compliance with Annex A 5.17 to mitigate the risk of password compromise.
- Required for all privileged or administrative access to critical systems.
- Highly recommended for remote access and cloud-based services.
- Protects against credential stuffing and brute-force attacks.
- Auditors typically flag the absence of MFA as a significant security weakness.
How should organisations manage default vendor passwords?
Default vendor passwords must be changed or disabled immediately upon the deployment of any new hardware, software, or system.
- Maintain a log of system installations that includes a “default password changed” sign-off.
- Avoid using the same “initial setup” password across multiple devices.
- Ensure that temporary passwords provided to users expire after the first login.
- Enforce these requirements during the technical onboarding of new infrastructure.
What are the user responsibilities under Annex A 5.17?
Users are responsible for maintaining the confidentiality of their authentication information and must not share, record, or store credentials in an insecure manner.
- Prohibit the sharing of individual user accounts or passwords.
- Educate staff on the dangers of writing passwords down or storing them in unencrypted files.
- Mandate the use of approved password managers for storing complex credentials.
- Require users to report suspected compromises of their authentication information immediately.
Does ISO 27001 allow for password-less authentication?
Yes, ISO 27001 is technology-neutral and permits password-less methods, provided they offer equivalent or superior security to traditional passwords.
- Includes biometric authentication (fingerprint, facial recognition).
- Supports hardware-based security keys (e.g., FIDO2/YubiKeys).
- Requires a risk assessment to ensure the chosen method is robust against spoofing.
- Must be supported by a formalised authentication management process.
What evidence do auditors expect for Annex A 5.17?
Auditors look for a combination of documented policies, technical configuration evidence, and records of user awareness training.
- A signed “Topic-Specific Policy on Authentication Information.”
- Screenshots of system settings showing password complexity and MFA enforcement.
- Records of password manager deployment and adoption across the workforce.
- Verification that default passwords for critical assets (e.g., routers, databases) have been changed.
Related ISO 27001 Controls
ISO 27001 Annex A 8.5 Secure Authentication
ISO 27001 Annex A 8.21 Security of Network Services
Further Reading
ISO 27001 Access Control Policy Beginner’s Guide
ISO 27001 controls and attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Protect | Identity and access management | #Protection |
| Integrity | ||||
| Availability |
