ISO 27001 Annex A 5.17 Authentication Information is a security control that establishes a formal management process for allocating and protecting credentials like passwords and biometrics. Implementing this control ensures confidentiality of secrets, providing a significant business benefit by preventing unauthorised access and mitigating credential-based breaches.
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 Audit ISO 27001 Annex A 5.17
- 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 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.17 FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 controls and attribute values
Do it Yourself ISO 27001
Our Lead-Auditor verified templates with expert support have a 100% success rate.
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.
I’ve sat in the Auditor’s chair for 20 years. These are the exact tools I use to guarantee a pass.
How to implement ISO 27001 Annex A 5.17
Implementing the ISO 27001 Annex A 5.17 control requires a robust approach to managing authentication information. As a Lead Auditor, I recommend following this structured process to ensure that passwords, biometrics, and cryptographic keys are protected throughout their entire lifecycle, from initial allocation to eventual revocation.
1. Formalise the Authentication Information Policy
Establishing a clear set of rules is the foundation of this control. You must document the organisational requirements for the creation, distribution, and protection of authentication information.
- Define minimum password length and complexity requirements.
- Specify the mandatory use of Multi-Factor Authentication (MFA) for all remote and privileged access.
- Document the prohibited practices, such as sharing credentials or storing them in unencrypted plain text files.
2. Update the Asset Register for Authentication Systems
You cannot protect what you have not identified. Ensure your Asset Register includes all systems, applications, and databases that store or process authentication data.
- Identify the owners of each authentication system.
- Classify the sensitivity of the authentication data held within each asset.
- Link these assets to your wider Information Security Management System (ISMS) for risk assessment purposes.
3. Provision Unique User Identifiers
Accountability is a core tenet of ISO 27001. You must ensure that every user is assigned a unique ID to maintain a clear audit trail of actions performed.
- Eliminate the use of shared or generic accounts, such as “admin” or “guest,” wherever technically possible.
- Assign Identity and Access Management (IAM) roles based on the principle of least privilege.
- Ensure that unique IDs are mapped directly to verified individuals.
4. Configure Multi-Factor Authentication (MFA)
Relying solely on passwords is no longer sufficient for modern security. Implementing MFA adds a critical layer of protection against credential theft.
- Deploy MFA for all cloud-based services and internal systems containing sensitive data.
- Utilise hardware tokens, biometrics, or authenticator apps rather than less secure SMS-based codes.
- Ensure the MFA solution is integrated into the central identity provider.
5. Enforce Technical Password Constraints
Use technical controls to enforce the policy requirements established in step one. This reduces the reliance on human diligence for security.
- Implement system settings that prevent the reuse of previous passwords.
- Enforce account lockout thresholds to mitigate the risk of brute-force or dictionary attacks.
- Enable “masking” of authentication information during entry to prevent shoulder surfing.
6. Secure Authentication Information Storage
The storage of authentication data must be resilient against unauthorised access or data breaches. This involves the use of strong cryptographic techniques.
- Ensure passwords are stored using salted, one-way cryptographic hashes.
- Protect cryptographic keys and biometric templates with encryption at rest.
- Limit administrative access to the underlying databases where authentication data resides.
7. Establish Secure Distribution Channels
The moment of credential issuance is a high-risk period. You must establish secure methods for delivering initial or reset authentication information to users.
- Verify the identity of the recipient before providing new credentials.
- Use secure, out-of-band communication channels for password delivery.
- Force an immediate password change upon the first login after a reset or initial provision.
8. Deliver Information Security Awareness Training
Users are often the weakest link in the authentication chain. Regular training ensures they understand their responsibilities in protecting their credentials.
- Conduct training sessions on how to recognise phishing attempts designed to steal credentials.
- Educate staff on the importance of keeping authentication information confidential.
- Provide guidance on the use of approved corporate password managers.
9. Implement Prompt Revocation Protocols
Authentication information must be managed through the entire employee lifecycle. Failure to revoke access promptly creates significant security gaps.
- Integrate HR termination processes with IT de-provisioning workflows.
- Ensure credentials are revoked or changed immediately upon an employee’s exit or a change in their role.
- Update the Record of Employment (ROE) documents to confirm the return of any physical authentication tokens.
10. Conduct Regular Access Audits
Continuous monitoring and review are essential to maintain the effectiveness of this control. Regular audits help identify orphaned accounts or policy violations.
- Perform quarterly reviews of privileged account access and activity.
- Audit logs for failed login attempts to identify potential brute-force patterns.
- Review the Asset Register and IAM roles to ensure they remain accurate and aligned with current business needs.
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 Audit ISO 27001 Annex A 5.17
As an ISO 27001 Lead Auditor, I have designed this audit process to verify that your organisation is effectively managing and protecting authentication information. Following these steps will ensure that your controls for Annex A 5.17 are not only documented but are technically robust and resistant to unauthorised access.
1. Inspect the Formal Authentication Information Policy
Examine the documented policy to ensure it establishes clear rules for the creation, distribution, and lifecycle management of authentication data.
- Confirm that the policy mandates Multi-Factor Authentication (MFA) for all remote and privileged access.
- Verify that password complexity, rotation requirements, and length are defined in alignment with industry best practices.
- Check that the policy explicitly prohibits the sharing or insecure storage of credentials.
2. Reconcile the Asset Register with Authentication Databases
Validate that all systems, applications, and databases that store or process authentication information are correctly identified and classified.
- Inspect the Asset Register to ensure it includes all Identity and Access Management (IAM) systems.
- Verify that the owners of these authentication assets are clearly assigned and aware of their security responsibilities.
- Cross-reference system logs with the register to identify any undocumented “shadow IT” authentication stores.
3. Evaluate Unique User IDs and IAM Role Assignments
Audit the system configurations to ensure that every individual is assigned a unique identifier to maintain accountability.
- Search for the use of shared or generic accounts, such as “Administrator” or “Support”, and verify if they have been disabled.
- Review IAM roles to confirm that the principle of least privilege is applied to each user identifier.
- Examine the process for verifying an individual’s identity before a unique ID is provisioned.
4. Validate the Enforcement of Multi-Factor Authentication (MFA)
Verify that technical controls are in place to enforce MFA across the organisational perimeter and for sensitive internal systems.
- Sample 10% of user accounts to confirm that MFA is active and cannot be bypassed by the user.
- Ensure that MFA methods used are resilient, such as hardware tokens or authenticator apps, rather than SMS-based codes.
- Test the system response when an MFA prompt is rejected to ensure access is denied immediately.
5. Test Technical Password Complexity and Lockout Constraints
Perform technical testing on system settings to confirm that policy requirements for passwords are being enforced automatically.
- Attempt to set a password that falls below the minimum complexity or length requirements to test system rejection.
- Verify that account lockout thresholds are active after a specified number of failed login attempts.
- Confirm that the system forces a password change upon initial login for all new or reset accounts.
6. Audit the Secure Storage and Hashing of Credentials
Examine the technical methods used to store authentication information to ensure it is protected from data breaches or unauthorised viewing.
- Review database configurations to confirm that passwords are stored using salted, one-way cryptographic hashes.
- Verify that biometric templates and cryptographic keys are encrypted at rest using industry-standard algorithms.
- Confirm that authentication information is masked during entry to prevent shoulder-surfing risks.
7. Verify Secure Delivery and Identity Verification Protocols
Inspect the process for distributing initial or reset authentication information to ensure it remains confidential during transit.
- Observe the service desk process for credential resets to ensure identity is verified before information is released.
- Verify that secure, out-of-band communication channels are used for the distribution of temporary credentials.
- Check that temporary credentials have a short expiration window and are invalidated after their first use.
8. Review Security Awareness Training Completion Rates
Examine training logs to ensure that all personnel understand their responsibilities regarding the protection of authentication information.
- Inspect the training materials to confirm they cover password hygiene, MFA usage, and phishing recognition.
- Verify that 100% of staff have completed the mandatory security awareness programme within the last 12 months.
- Review records of targeted training provided to privileged users who manage authentication systems.
9. Confirm Immediate Revocation via Record of Employment (ROE) Logs
Audit the offboarding process to ensure that authentication information is revoked immediately when an individual leaves the organisation.
- Sample the last five employee exits and compare their departure date with the timestamp of their account deactivation.
- Review Record of Employment (ROE) documents to ensure physical authentication tokens have been returned and decommissioned.
- Verify that access is revoked or modified immediately upon a change in job role or responsibilities.
10. Examine Periodic Access Review and Log Monitoring Reports
Analyse the output of regular monitoring activities to ensure the continued effectiveness of authentication controls.
- Review the reports from the last quarterly access review to ensure that “orphaned” accounts were identified and removed.
- Inspect system logs for evidence of monitoring for brute-force attacks or suspicious login patterns.
- Confirm that any identified security incidents related to authentication were managed according to the formal incident response plan.
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
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. • No Post-its: A “Clean Desk Policy” check to ensure Wi-Fi or login passwords aren’t written on sticky notes attached to monitors. |
| 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. • SSH Key Rotation: A policy requiring developers to rotate their SSH keys annually or immediately upon leaving the company. |
| 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. • Token Expiry: Using short-lived access tokens for data scientists accessing sensitive PII training buckets, rather than permanent access keys. |
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 Applicable Laws and Related Standards
| Framework / Law | Relevant Section / Control | Mapping Context & Implementation Focus |
|---|---|---|
| NIST CSF v2.0 | PR.AA-P1 / PR.AA-P2 | Focuses on identity management and authentication. Requires MFA and cryptographically secure storage of credentials. |
| NIS2 Directive (EU) | Article 21 | Mandates security in network and information systems. Authentication is a minimum measure for essential and important entities. |
| DORA (EU) | Article 9 | High-resilience authentication for financial entities to prevent unauthorised access to ICT systems. |
| SOC 2 (AICPA) | CC6.1 / CC6.3 | Part of the Logical and Physical Access criteria. Focuses on identity verification and credential lifecycle management. |
| GDPR (EU) | Article 32 | Defines appropriate technical and organisational measures. Weak authentication is often cited as a failure in data protection. |
| UK Data (Use and Access) Act 2025 | Section 1 (Smart Data & Trust) | The evolution of GDPR focusing on reduced administrative burdens. Maintains high security thresholds for digital identity and secure data access. |
| Cyber Security and Resilience Bill (UK) | Supply Chain Security | The UK answer to NIS2. Expands mandatory reporting for MSPs and requires strong authentication to protect service management planes. |
| CIRCIA (USA) | Reporting Triggers | Mandatory 72-hour reporting for critical sectors. Assumes robust IAM is in place to accurately detect and report unauthorised access events. |
| EU AI Act | Article 15 (Cybersecurity) | Requires high-risk AI systems to be resilient against unauthorised third parties attempting to alter performance via credential theft. |
| ISO/IEC 42001 (AI) | Annex A 8.3 | Maps AI system access to standard IAM. Protects the training data environment and model weights through strict authentication. |
| EU Product Liability Directive (PLD) Update | Article 6 (Defectiveness) | Extends strict liability to software. Insecure authentication, such as hardcoded passwords, can be deemed a product defect. |
| ECCF (European Cybersecurity Certification Framework) | Level Substantial | Move towards EU-wide harmonised security labels. Requires MFA and secure credential storage for certified products and services. |
| HIPAA (USA) | 45 CFR § 164.312(a)(2)(i) | The Unique User Identification and Authentication standard required for protecting electronic Protected Health Information (ePHI). |
| CCPA / CPRA (California) | Section 1798.150 | Provides a private right of action for breaches resulting from a failure to maintain reasonable security, specifically regarding credential protection. |
| PCI DSS v4.0 | Requirement 8 | Requires MFA for all access to the Cardholder Data Environment (CDE) and defines strict password complexity and rotation rules. |
Modern Authentication: Passkeys, FIDO2, and Zero Trust
Let us be completely honest for a second. Passwords are an absolute nightmare to manage and they are the root cause of most data breaches. The ISO 27001 standard is technology-agnostic, which means you do not actually have to use passwords at all. In fact, moving to a passwordless environment is the smartest thing you can do for your compliance and your sanity.
As an auditor, I love seeing organisations adopt FIDO2 security keys (like YubiKeys) or Passkeys. These cryptographic methods are practically immune to phishing. If you are implementing a Zero Trust architecture where you verify not just the user, but the health of their device and their location before granting access, you are going to breeze through this part of the audit. Stop relying on human memory and start relying on cryptography.
Key Performance Indicators (KPIs) for Annex A 5.17
Auditors do not just want to see that you wrote a policy. They want to see that your policy actually works in the real world. How do you prove that? You measure it. If you want to demonstrate true continuous improvement, you should be tracking specific metrics around your authentication management.
- MFA Coverage: The percentage of active user accounts with Multi-Factor Authentication successfully enabled. Your target here must be exactly 100%.
- Revocation Speed: The average time it takes to revoke access after an employee is terminated. It should be measured in minutes or hours, not days.
- Compromise Rate: The number of account compromise incidents per quarter resulting from credential stuffing or phishing.
- Hardware MFA Adoption: The percentage of your highly privileged administrative accounts protected by hardware tokens rather than easily intercepted SMS codes.
Acceptable Cryptographic Standards for Password Storage
If you are building your own software or managing an internal database, how you store the authentication information is critical. The standard requires confidentiality, and in the technical world, that means proper cryptographic hashing and salting.
If I look under the hood during an audit and see you are storing passwords in clear text, or using deprecated algorithms like MD5 or SHA-1, I am raising a major non-conformity immediately. You must use modern, computationally expensive algorithms designed specifically for password hashing. Argon2 is currently the gold standard, followed closely by bcrypt and PBKDF2. Apply a unique, random salt to every single password before hashing it. This stops attackers from using pre-computed rainbow tables if your database is ever compromised.
Incident Response: Handling Compromised Credentials
Even with the best controls in place, mistakes happen. A user will eventually click a sophisticated phishing link and hand over their authentication information. ISO 27001 is fundamentally about risk management, which means you need a plan for when things go wrong.
Your authentication procedures must tie directly into your Incident Response Plan. When a credential compromise is suspected, your team needs a documented, rapid-fire response process. This includes forcing an immediate, global password reset for the affected user, invalidating all active session tokens, and isolating the account while you review access logs for lateral movement. Do not wait for an auditor to ask what happens when an account gets breached. Have the playbook ready and tested.
Recommended IAM and PAM Tooling
Governance and policies are my bread and butter, but you cannot realistically manage authentication for a growing company using spreadsheets. You need the right technology to enforce the rules we write in the policy.
When I conduct audits, the organisations that pass with flying colours are usually leveraging enterprise-grade Identity and Access Management (IAM) and Privileged Access Management (PAM) tools. Here is what you should be looking at:
- Identity Providers (IdP): Systems like Microsoft Entra ID, Okta, or Google Workspace allow you to centralise authentication and enforce MFA universally across all your integrated apps.
- Privileged Access Management (PAM): For your IT administrators and super users, tools like CyberArk or Delinea securely vault high-level credentials and rotate them automatically.
- Business Password Managers: For the random credentials that cannot be rolled into your Single Sign-On environment, issue corporate password managers like 1Password, Bitwarden, or Keeper to your staff. It stops them from writing passwords on sticky notes and failing my desk checks.
Integration with NIST 800-63B
If you want to build a skyscraper level of compliance and truly impress your auditor, you align your ISO 27001 implementation with the technical depths of NIST. When it comes to authentication, the global gold standard is NIST SP 800-63B (Digital Identity Guidelines).
NIST breaks authentication down into Authenticator Assurance Levels (AALs). Instead of guessing what makes a password strong enough for your risk appetite, NIST provides the exact mathematical and procedural requirements. By mapping your ISO 27001 Annex A 5.17 controls to meet NIST AAL2 (which mandates proper MFA) or AAL3 (which requires hardware-based cryptographic authenticators for critical systems), you completely remove the guesswork. You can tell the auditor exactly why your authentication is secure, backed by the most respected cybersecurity framework in the world.
Machine-to-Machine and API Authentication
One of the biggest mistakes I see during an audit is a company that beautifully manages employee passwords but completely ignores their non-human identities. Systems have to talk to other systems. That means service accounts, API keys, and OAuth tokens.
ISO 27001 Annex A 5.17 applies to these secrets just as strictly as it applies to a human’s password. If your developers are hardcoding API keys into GitHub repositories, or if you have a service account with a password that has not been changed since 2018, you are failing this control.
- Vault Your Secrets: You must use a dedicated secrets manager like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault.
- Automated Rotation: Machine authentication information should be rotated automatically. No human should need to manually update a database connection string.
- Least Privilege for APIs: API tokens must be scoped to perform only the exact actions required, rather than granting blanket administrative access.
Managing Third-Party and Vendor Authentication
When an employee leaves, your HR system triggers an automated offboarding process. But what happens when a six-month contract with an external marketing agency ends? All too often, their authentication information remains active for years.
You must establish a formal boundary for third-party authentication. Whenever possible, external vendors should authenticate using their own Identity Provider through Federation or Single Sign-On (SSO). If you must issue them local credentials to your systems, those credentials must have a hardcoded expiration date. Do not leave the door open hoping someone remembers to close it when the project finishes. Force the system to revoke the authentication information automatically.
The Annex A 5.17 Evidence Request List
Let us cut to the chase. When I am auditing your Information Security Management System, I do not just want to hear you talk about your controls. I need to see the proof. If you want to breeze through the Annex A 5.17 portion of your audit, have a zip folder ready with the following exact artifacts:
- The Policy Document: Your formal, version-controlled Access Control and Authentication Policy, showing management approval within the last 12 months.
- MFA Enforcement Screenshots: Screenshots from your central directory (e.g., Microsoft Entra ID or Google Workspace) proving that MFA is globally enforced for all users, with no exceptions for administrators.
- Password Configuration Exports: A system export showing your active password constraints (minimum length, complexity rules, and lockout thresholds after failed attempts).
- New Hire Provisioning Tickets: Two recent IT service desk tickets showing the secure, verified allocation of initial authentication information to a new employee.
- Termination Logs: Evidence from your system logs showing that authentication rights for a recently departed employee were revoked on their exact termination date.
- Default Password Checks: A documented checklist or configuration standard proving that default vendor credentials on a recently deployed server or network switch were changed before going into production.
Defeating Helpdesk Social Engineering and AI Deepfakes
You can have the strongest cryptographic passkeys in the world, but it means absolutely nothing if an attacker can just call your IT helpdesk, claim they lost their phone, and get a temporary password issued. Hackers do not hack systems anymore. They hack people.
With the rise of AI voice cloning and deepfakes, your helpdesk cannot rely on recognising a voice. ISO 27001 Annex A 5.17 explicitly requires a secure process for the allocation of authentication information. You must have a bulletproof identity verification process before anyone touches a reset button.
- Manager Approval Workflows: Require a direct manager to approve the password reset request via a secondary channel before the helpdesk actions it.
- Video Verification: For high-risk or privileged accounts, mandate a quick video call where the user holds up their corporate ID badge.
- Self-Service Password Reset (SSPR): Remove the human element entirely. Implement an SSPR tool that requires the user to authenticate via a secondary registered device or email address before resetting their primary credentials.
Legacy Systems and Compensating Controls
It is very easy to say “enforce MFA everywhere and mandate 16-character passwords.” But what happens when you have a 15-year-old manufacturing control system, or a bespoke legacy database that only accepts a 4-digit PIN and crashes if you try to integrate SSO?
Auditors live in the real world. We know legacy systems exist. If a system absolutely cannot comply with your strict authentication policy due to technical limitations, you must document it as an exception and apply compensating controls.
- Network Isolation: Put the legacy system on a highly restricted VLAN. If it has weak authentication, ensure it cannot be accessed from the public internet or even the general staff Wi-Fi.
- Jump Servers: Require users to log into a secure, MFA-protected jump server or bastion host. Only from that heavily monitored environment can they access the legacy system with the weaker credentials.
- Aggressive Monitoring: Implement strict alerting on the legacy system. If a failed login attempt occurs, your security team should know about it instantly.
The Biometric Privacy Trap (GDPR Collision)
Biometrics like fingerprints and facial recognition are fantastic for satisfying Annex A 5.17 because they prove the user’s identity based on who they are, rather than what they know. However, using biometrics introduces a massive legal minefield.
Under regulations like the GDPR, biometric data is classified as “special category data.” It requires explicit consent and incredibly strict protection. If you are rolling out centralized biometric authentication, you are instantly escalating your data privacy risks.
- Local Storage Only: Do not store biometric templates on a central server. Use technologies like Windows Hello or Apple FaceID where the biometric data never leaves the local device. The device simply sends a cryptographic token to the server to confirm a successful match.
- Always Offer Alternatives: You cannot usually force an employee to hand over their biometric data. You must provide a secure alternative, such as a hardware token or a complex passphrase, for users who opt out.
- Update Your Privacy Notice: Ensure your employee privacy notices clearly state how authentication information is processed, stored, and eventually destroyed.
AI-Driven Adaptive Authentication (Behavioral Biometrics)
Static passwords are a liability and even standard MFA is showing its age. The cutting edge of Annex A 5.17 compliance is Continuous Risk-Based Authentication powered by AI.
Instead of just asking for a password at 9:00 AM, modern Identity and Access Management (IAM) systems use machine learning to constantly evaluate the user’s session. The AI builds a baseline of normal behavior. It looks at your typing cadence, your mouse movements, the exact time of day you usually log in, and your typical IP address. If your credentials are compromised and an attacker logs in, the AI immediately flags the anomalous behavior and forces a step-up authentication challenge or simply kills the session.
- Implement Behavioral Analytics: Look for Identity Providers that offer AI risk scoring. This satisfies the standard’s requirement for a robust management process by actively preventing unauthorised access even after a successful login.
- Continuous Verification: Document your use of adaptive authentication in your Access Control Policy. Auditors absolutely love to see proactive, automated security controls that do not rely on human memory.
Authenticating Autonomous AI Agents
We covered standard machine-to-machine APIs earlier, but the industry is rapidly moving towards autonomous AI agents. These are Large Language Models (LLMs) that do not just read data; they take actions on behalf of a human user. They draft emails, query databases, and update financial records.
How do you issue authentication information to an AI agent? This is a massive compliance headache that most companies are completely ignoring right now. If an AI agent deletes a client database, your audit trail needs to show exactly which authentication token authorised that action and which human originally approved the agent’s permissions.
- Agent-Specific Identities: Never let an AI agent inherit a human user’s full privileges. AI agents must have their own highly restricted, identity-verified service accounts.
- Short-Lived Tokens: AI agents should operate on ephemeral, short-lived access tokens. If the agent goes rogue or is hijacked via a prompt injection attack, the authentication token should expire in minutes.
- Human-in-the-Loop Verification: For critical systems, the AI agent’s authentication should only allow it to draft an action. A verified human must still provide their own MFA token to actually execute the change.
The Password Rotation Debate: NIST vs. Traditional Auditors
For decades, security policies mandated that users change their passwords every 30, 60, or 90 days. Some older ISO 27001 auditors still expect to see this. But let me be perfectly clear: forced arbitrary password rotation is now considered a bad practice.
Organisations like NIST and the NCSC (National Cyber Security Centre) have proven that forcing frequent changes causes “password fatigue.” Users just take their existing password and add a “1”, then a “2”, then a “3” to the end of it. It makes passwords weaker, not stronger.
So, how do you handle an old-school auditor who asks why you are not forcing 90-day password resets?
- Document the Justification: In your Access Control Policy, explicitly state that you align with NIST 800-63B guidelines. State that passwords are only forced to change if there is evidence of a compromise.
- Rely on Compensating Controls: Show the auditor that because you have enforced MFA, implemented breached-password screening, and use adaptive risk-based authentication, arbitrary rotation is technically unnecessary and actively harms user experience.
Physical Authentication Information: Smart Cards and PINs
A massive blind spot for many IT teams is thinking Annex A 5.17 only applies to logical access, like logging into a computer or a cloud app. The standard applies to all authentication information, and that includes the physical realm.
If you have a server room secured by a keypad, or an office accessed via RFID smart cards, that is authentication information. If everyone uses the same 4-digit PIN to get into the server room, you have a major non-conformity on your hands. You cannot prove who entered the room.
- Unique Physical Credentials: Keypad PINs for highly restricted physical areas must be unique to the individual and heavily restricted.
- Deactivation Workflows: Just like software passwords, physical smart cards and fobs must be deactivated the moment an employee is terminated or a contractor finishes their project.
- Protecting the Tokens: Personnel must be trained on the risks of badge cloning. Leaving an access badge visible on the dashboard of a car is the physical equivalent of leaving a password on a sticky note.
Device Trust and Conditional Access
We have authenticated the user. We have even authenticated the AI. But what about the laptop or the mobile phone the user is holding? In a modern Zero Trust architecture, verifying the human is only 50% of the job.
If a user provides a perfectly valid password and a perfectly valid MFA token, but they are logging in from an unpatched, malware-infected personal laptop in a foreign country, should you grant them access? Absolutely not.
- Implement Conditional Access Policies: Your IAM system (like Microsoft Entra ID) should check the compliance state of the device before accepting the authentication information. Is the disk encrypted? Is the antivirus running?
- Mobile Device Management (MDM): Ensure that authentication to corporate resources is restricted exclusively to devices enrolled in your MDM platform. If an employee tries to access your CRM from their child’s iPad, the authentication should be blocked, regardless of whether the password is correct.
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 and Further Reading
| Related ISO 27001 Control | Auditor’s Relationship Context |
|---|---|
| ISO 27001 Annex A 5.15 Access Control | This is the ‘Why’ behind the ‘How’. Access Control defines the rules of who gets into what, while 5.17 provides the technical keys (passwords/MFA) to make those rules a reality. |
| ISO 27001 Annex A 5.16 Identity Management | You cannot authenticate a ghost. Identity Management covers the lifecycle of the user identity itself, whereas 5.17 focuses strictly on the ‘secret’ information used to prove that identity. |
| ISO 27001 Annex A 5.18 Access Rights | Once authenticated via 5.17, the system needs to know what the user is allowed to do. These controls work in tandem to ensure the right person has the right level of access. |
| ISO 27001 Annex A 8.5 Secure Authentication Log-on | This is the technical ‘front door’. While 5.17 manages the data (the password), 8.5 manages the interface where that data is entered, ensuring it doesn’t leak info during the login process. |
| ISO 27001 Annex A 8.2 Privileged Access Rights | The stakes are higher here. This control mandates that authentication information for ‘Super Users’ must be handled with even greater rigour, almost always requiring MFA. |
| ISO 27001 Annex A 7.2 Learning and Awareness | The most secure password policy in the world fails if staff don’t understand the risks. This control ensures users are trained on how to handle their 5.17 authentication data. |
| ISO 27001 Annex A 8.24 Use of Cryptography | This is the ‘How’ of storage. We use the cryptographic principles defined in 8.24 to salt and hash the authentication information managed under 5.17. |
| ISO 27001 Annex A 5.33 Protection of Information Systems During Audit Testing | During an audit, we must ensure that ‘live’ authentication information is never used or exposed in test environments, maintaining the integrity of 5.17 data. |
| ISO 27001 Annex A 8.3 Information Access Restriction | This control provides the technical ‘No Entry’ signs. It works with 5.17 to ensure that if authentication fails, the restriction is absolute and the data remains hidden. |
| ISO 27001 Annex A 5.1 Policies for Information Security | The high-level parent. Your password and MFA requirements in 5.17 must be officially blessed by the overarching security policies defined in 5.1. |
ISO 27001 Annex A 8.21 Security of Network Services
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 |
About the author
