ISO 27001 A.5.17: Authentication Information

ISO 27001 A.5.17 requires that authentication information, the passwords, keys, tokens, and secrets people and systems use to prove identity, is allocated and managed under a controlled process from issuance through revocation. It is an Organizational control (A.5), and teams get flagged most often on unmanaged secrets rather than a missing password rule: API keys and service-account credentials hard-coded in a repository or a config file, with no vault, no rotation, and no record of who holds them.

What is ISO 27001 A.5.17?

ISO 27001 A.5.17 Authentication information is the control that governs the lifecycle of the secrets used to authenticate. ISO/IEC 27001:2022, Annex A titles it Authentication information and frames it around the allocation and management of that information: how it is issued, how users are told to protect it, how it is stored, and how it is changed or revoked. It covers the credentials themselves rather than the act of logging in with them.

A.5.17 falls between two controls it should not be confused with. A.5.16 Identity management governs the identities that credentials belong to, the accounts and their unique identifiers. A.8.5 Secure authentication governs the log-on procedure that puts credentials to work: how many factors, how failed attempts are handled, how the session is established. A.5.17 owns everything about the secret between those two: allocating it securely, protecting it in storage, and retiring it when it is no longer needed.

How do you implement A.5.17?

Implement A.5.17 by putting every category of authentication information under a managed lifecycle, from the moment it is issued to the moment it is revoked. The sequence a team runs:

1. Control initial allocation and force a first-change. Issue initial passwords and credentials through a secure channel, tie the allocation to a verified identity, and require the credential to be changed on first use so no human other than the holder ever knows the working secret. Capture the user's acknowledgement of their responsibility to keep the credential confidential.
2. Protect stored authentication information. Store user passwords salted and hashed with a strong, purpose-built algorithm (such as bcrypt, scrypt, or Argon2), never in plain text and never with reversible encryption. Keys and tokens that must be retrievable live in a secrets manager rather than in source code, environment files committed to a repository, or a shared spreadsheet.
3. Manage secrets and API keys in a vault. Machine credentials, API keys, service-account tokens, and signing keys belong in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager) with access scoped by policy and every retrieval logged. Applications fetch secrets at runtime rather than embedding them.
4. Rotate and revoke on a defined schedule and on trigger. Set rotation intervals for long-lived secrets, and revoke immediately on compromise, on personnel change, or when a credential is no longer needed. Short-lived, automatically rotated credentials reduce the window a leaked secret is useful.
5. Change vendor and product default credentials before anything goes live. Most appliances, databases, and applications arrive with default or well-known credentials. Change them as a step in provisioning and record that the change happened, because default credentials are among the most reliably exploited weaknesses.
6. Set password quality per NIST SP 800-63B. Where humans choose passwords, base the rules on the current standard: an 8-character minimum with MFA enforced, or 15 characters without it, no forced composition rules, no routine forced rotation, and screening of new and changed passwords against a breached-password list. This is the credential-quality rule that A.5.17 owns; A.8.5 Secure authentication enforces it at the log-on step.

Cloud vs on-prem

The A.5.17 lifecycle is the same in either environment; the tooling that carries it differs. In the cloud, the identity provider (Okta, Entra ID, Google Workspace) holds and rotates user credentials, and a managed secrets manager holds machine secrets with retrieval logged and access scoped by policy. On-prem, Active Directory handles credential issuance and password policy, and a self-hosted vault or an HSM holds keys and service-account secrets, with local accounts on non-domain systems governed by the same rules. Where secrets are held and how applications fetch them at runtime is a design-level decision, the kind a security architecture review examines end to end. The SOC 2 access control on-prem guide covers the on-prem credential and directory handling in depth.

What evidence demonstrates A.5.17?

Evidence for A.5.17 is the record that authentication information is issued, stored, and retired under control, led by the credential-management procedure and the configuration that shows it operates.

How does A.5.17 map to SOC 2?

A.5.17 is a Full overlap with SOC 2 CC6.1. Both govern the credentials, password controls, and secrets management that restrict logical access, so the same evidence serves both audits without adaptation.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including the other access-control controls (A.5.15, A.5.16, A.5.18, A.8.3, A.8.5) that CC6.1 also touches, and where existing SOC 2 work transfers to ISO 27001.

Related controls

A.5.17 manages the credentials themselves, and it works alongside the access-control controls around it. A.8.5 Secure authentication governs the log-on procedure that puts those credentials to work, including MFA and failed-attempt handling. A.5.16 Identity management governs the identities the credentials belong to, and A.5.15 Access control sets the policy for who is granted access in the first place. A.8.24 Use of cryptography governs the key management that protects stored authentication information. All fall within the access-control scope covered by the ISO 27001 certification guide.

Part of Truvo's control-by-control ISO 27001 reference series, anchored by the ISO 27001 certification guide.

Frequently Asked Questions

What is ISO 27001 A.5.17?

ISO 27001 A.5.17 Authentication information is an Organizational control in Annex A of ISO/IEC 27001:2022. It governs the lifecycle of the secrets used to authenticate, including passwords, keys, tokens, and API secrets: how they are allocated, how users are told to protect them, how they are stored, and how they are rotated and revoked. It covers the credentials themselves rather than the act of logging in with them.

What evidence satisfies A.5.17?

A.5.17 evidence is led by the credential issuance and management procedure and the password policy citing NIST SP 800-63B, supported by configuration that shows they operate: secrets-manager configuration and access logs, default-credential change records, password hashing and credential-storage configuration, and rotation and revocation records. Together these show authentication information is issued, stored, and retired under control.

How is A.5.17 different from A.8.5?

A.5.17 Authentication information manages the credentials themselves: how passwords, keys, and secrets are allocated, stored, rotated, and revoked. A.8.5 Secure authentication governs the log-on procedure that uses those credentials: how many factors are required, how failed attempts are handled, and how the credential is protected while it travels and while the session is open. A.5.17 owns the secret; A.8.5 owns the login that consumes it.

How is A.5.17 different from A.5.16 identity management?

A.5.16 Identity management governs the identities themselves, the accounts and their unique identifiers, and the process for creating, changing, and removing them. A.5.17 governs the authentication information those identities use to prove who they are. An identity is the account; authentication information is the secret that account holds. The two are complementary controls rather than duplicates.

Does A.5.17 require a secrets manager?

A.5.17 does not name a specific tool, but a secrets manager is the common way to satisfy it for machine credentials, API keys, and service-account tokens. The control requires that authentication information is stored and protected under control, with access restricted and changes managed. A vault such as AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, or GCP Secret Manager provides scoped access, logged retrieval, and rotation, which is stronger than secrets embedded in source code or configuration files.

What password rules does A.5.17 expect?

A.5.17 does not mandate a specific standard, but NIST SP 800-63B is the most commonly adopted basis for the password-quality portion. Its current guidance is an 8-character minimum with MFA enforced, or 15 characters without, with forced composition rules and routine forced rotation dropped, and new passwords screened against a breached-password list. Citing NIST SP 800-63B in the policy gives the auditor confidence the rules are deliberate rather than arbitrary.