How to Implement ISO 27001 Annex A 5.17

Implementing ISO 27001 Annex A 5.17 is a critical security imperative that mandates a formalised authentication lifecycle to prevent unauthorised access. By enforcing technical verification of secrets and robust hashing, organizations achieve the primary business benefit of reduced credential-based breaches and sustained regulatory compliance.

ISO 27001 Annex A 5.17 Authentication Information Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.17. This guide focuses on the manual hardening and technical verification of authentication secrets to ensure security is embedded at the system level rather than a superficial dashboard.

1. Establish the Authentication Lifecycle Policy

Control Requirement: A formalised process must exist for the creation, distribution, storage, and revocation of authentication information.

Required Implementation Step: Draft a technical standard that defines password complexity, MFA requirements, and the prohibition of shared accounts. Document the specific technical mechanisms (e.g., bcrypt, Argon2) used for hashing across all local and cloud databases.

Minimum Requirement: A signed policy document and a technical configuration standard mapped to every production system.

2. Secure Initial Distribution of Credentials

Control Requirement: Authentication information must be distributed securely to the intended recipient upon account creation.

Required Implementation Step: Disable the practice of sending initial passwords via email or Slack. Implement a “one-time secret” link or a physical handover process where the user is forced to rotate the credential upon first login before access to the production environment is granted.

Minimum Requirement: Evidence of a forced password change on first-time login for the last 10 onboarded users.

3. Verify Cryptographic Storage of Secrets

Control Requirement: Authentication information must be protected against unauthorised disclosure or modification during storage.

Required Implementation Step: Inspect the database schema for all bespoke applications. Verify that no passwords are stored in cleartext or reversible encryption; ensure they are salted and hashed using modern, industry-standard algorithms within the configuration files.

Minimum Requirement: A database export or screenshot demonstrating that the “password” column contains only non-reversible hashes.

4. Implement Hardened Multi-Factor Authentication (MFA)

Control Requirement: Systems must support and enforce multi-factor authentication for sensitive access.

Required Implementation Step: Manually configure MFA at the identity provider (IdP) or server level (e.g., PAM modules on Linux). Ensure that MFA is “always-on” for administrative interfaces and that “remember me” durations are restricted to a maximum of 12 hours.

Minimum Requirement: Configuration logs showing MFA enforcement for 100% of privileged administrator accounts.

5. Prohibit the Use of Default Credentials

Control Requirement: Default vendor-supplied authentication information must be changed or disabled upon installation.

Required Implementation Step: Conduct a manual audit of all network hardware, IoT devices, and software instances. Change “admin/admin” or “root/password” combinations immediately and document the change in the system hardening log.

Minimum Requirement: A hardening report confirming that default credentials have been rotated on all firewall and switch interfaces.

6. Enforce Account Lockout and Brute-Force Protection

Control Requirement: Measures must be in place to prevent automated guessing or brute-force attacks on authentication info.

Required Implementation Step: Configure account lockout thresholds (e.g., 5 failed attempts) and progressive delays (throttling) within the application code or web server configuration (e.g., fail2ban). Ensure these logs are sent to a central log aggregator for alerting.

Minimum Requirement: A successful test result showing an account being locked out after the maximum allowed failed attempts.

7. Secure Management of Privileged Service Accounts

Control Requirement: Non-human authentication info (API keys, service accounts) must be managed with equal or greater rigour.

Required Implementation Step: Move service account secrets out of environment variables and plaintext config files. Inject them at runtime using a dedicated secret manager (like HashiCorp Vault) and implement a 90-day rotation schedule for all API keys.

Minimum Requirement: A screenshot of the secret management vault showing active rotation policies for all production API keys.

8. Regular Review and Revocation of Credentials

Control Requirement: Authentication information must be revoked immediately upon termination or change of role.

Required Implementation Step: Synchronise the HR leavers list with the Active Directory or IdP. Manually audit local “shadow” accounts on legacy servers that are not integrated into the central SSO to ensure no former employees retain access.

Minimum Requirement: A reconciled report showing that all accounts for employees who left in the last 30 days are “Disabled”.

9. Educate Users on Secret Handling

Control Requirement: Users must be aware of their responsibilities for keeping authentication info confidential.

Required Implementation Step: Deliver a technical briefing specifically for developers and sysadmins on the dangers of hardcoding secrets in Git repositories. Implement pre-commit hooks that scan for secrets before they are pushed to the codebase.

Minimum Requirement: Training records for the technical team and a log of “clean” scans from the secret-detection tool.

10. Audit Authentication Logs for Anomalies

Control Requirement: Access and changes to authentication information must be logged and monitored.

Required Implementation Step: Configure system logs to capture successful logins, failed attempts, and password changes. Set up a manual monthly review process to inspect logs for “impossible travel” or suspicious credential-stuffing patterns that automated tools might miss.

Minimum Requirement: A signed log review report for the previous month, highlighting any investigated security events.

ISO 27001 Annex A 5.17 SaaS / GRC Platform Implementation Failure Checklist

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
Lifecycle Management	The GRC tool links to a PDF policy and marks the control as “Green”.	The tool has no visibility into whether the policy is actually followed in the server room.
Secure Storage	Dashboard reports “Encryption at rest” based on a cloud provider API.	It doesn’t check if the application is hashing passwords before they hit the encrypted disk.
MFA Enforcement	The tool sees an “MFA Enabled” toggle in Microsoft 365.	It misses the legacy IMAP/POP3 ports that allow attackers to bypass MFA entirely.
Default Credentials	GRC platforms assume defaults are changed because “Security Policy” says so.	They cannot scan your internal CCTV or printer VLANs where “admin/admin” usually survives.
Service Accounts	The tool ignores service accounts as they are “non-human”.	Hardcoded API keys in GitHub are the #1 cause of breaches, which GRC tools rarely scan.
Revocation	The tool checks if a user is “Deleted” in the primary SSO.	It fails to find the local ‘root’ or ‘maintenance’ accounts shared by the team.
Password Strength	The GRC tool checks the “Setting” in the Azure portal.	It doesn’t verify if developers have bypassed these settings for “test” accounts in production.
Credential Integrity	The tool relies on self-attestation from system owners.	System owners often lie or don’t understand the underlying crypto implementation.

About the author