# ISO 27001 A.5.17: Authentication Information

Source: https://truvocyber.com/blog/iso-27001-a-5-17-authentication-information
Published: 2026-08-03
Topic cluster: ISO 27001

> ISO 27001 A.5.17 authentication information: how to allocate, store, and rotate passwords, keys, and secrets, the evidence auditors expect, and the SOC 2 CC6.1 map.

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.

At a glance

- **Theme:** Organizational (A.5)

- **Source:** ISO/IEC 27001:2022, Annex A

- **New in 2022:** No

- **SOC 2 mapping:** [CC6.1](/blog/soc-2-cc6-1-logical-access-security) (Full)

- **Part of:** the [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies)

## 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](/blog/iso-27001-a-5-16-identity-management) governs the identities that credentials belong to, the accounts and their unique identifiers. [A.8.5 Secure authentication](/blog/iso-27001-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.

Key insight

**A.5.17 manages the credential, A.8.5 governs the login, A.5.16 owns the identity**

The three access-control controls are complementary. A.5.17 Authentication information is the lifecycle of the secret: how a password, key, token, or API secret is issued, stored, rotated, and revoked. Treat it as the control that keeps the credential itself managed, separate from the log-on mechanism A.8.5 secures and the identities A.5.16 maintains.

## 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](/blog/iso-27001-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](/blog/security-architecture-review-process) examines end to end. The [SOC 2 access control on-prem guide](/blog/soc2-access-control-on-prem) covers the on-prem credential and directory handling in depth.

Lifecycle element
Cloud
On-prem / self-hosted

User credential issuance and policy
IdP-managed, forced first change
Active Directory, GPO password policy

Machine secrets and API keys
Managed secrets manager, runtime fetch
Self-hosted vault or HSM

Rotation
Automated rotation on schedule
Scheduled rotation, documented for local accounts

Default-credential changes
Provisioning scripts and baseline images
Hardening checklist per device

## 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.

Artifact
What it demonstrates
Cadence

Credential issuance and management procedure
Authentication information is allocated through a controlled process with user acknowledgement
Reviewed at least annually

Password policy document citing NIST SP 800-63B
Password quality rules are deliberate and traceable to a recognized standard
Reviewed at least annually

Secrets-manager configuration and access logs
Keys and API secrets are vaulted, access-scoped, and retrieval is logged
Point-in-time plus continuous logging

Default-credential change records
Vendor and product defaults are changed before systems go live
Per system provisioned

Password hashing and credential-storage configuration
Stored credentials are salted and hashed, never plain text or reversible
Point-in-time per audit period

Rotation and revocation records
Secrets are rotated on schedule and revoked on trigger
Per rotation and per revocation event

Watch out

**Machine secrets left in code are the A.5.17 gap that gets missed**

Many teams put the human password policy under a microscope and leave API keys and service-account tokens hard-coded in a repository or a config file. A.5.17 covers both, and the secrets in code are usually the larger exposure. Move machine credentials into a secrets manager with scoped access and logged retrieval before the audit rather than after.

A common gap that comes up during readiness work is a password policy built on rules the referenced standard has retired. A team preparing for certification carries forward the composition requirements it remembers from ten years ago, mandatory uppercase, lowercase, number, and special character, plus a forced 90-day rotation, and assumes stricter is safer.

NIST SP 800-63B moved away from both: with MFA enforced, an 8-character minimum is sufficient, composition rules are dropped, routine rotation is dropped, and new passwords are screened against a breached-password list instead. Rewriting the policy to the current standard and citing NIST SP 800-63B as its basis simplifies the rules for users and produces a stronger, more defensible artifact for the auditor at the same time.

Free download · Excel

ISO 27001 Evidence Checklist

The evidence list an internal auditor works from: 138 items across clauses 4 to 10 and all 93 Annex A controls, with owner, status and location columns ready for your team. Enter your email to download it.

(function initLmChecklist(){ if (window.hbspt && window.hbspt.forms) { window.hbspt.forms.create({ region: "na3", portalId: "341945322", formId: "e9f8aeed-ff99-4c1b-860f-5eafb34bc993", target: "#lm-iso-evidence-list-form", css: "" }); } else { setTimeout(initLmChecklist, 200); } })();

## How does A.5.17 map to SOC 2?

A.5.17 is a Full overlap with SOC 2 [CC6.1](/blog/soc-2-cc6-1-logical-access-security). Both govern the credentials, password controls, and secrets management that restrict logical access, so the same evidence serves both audits without adaptation.

SOC 2 criteria
Overlap type
Evidence reusable in both directions

CC6.1 (restricts logical and physical access)
Full
Credential issuance procedure, password policy citing NIST SP 800-63B, secrets-manager configuration and access logs, credential-storage (hashing) configuration, rotation and revocation records

The [SOC 2 to ISO 27001 control mapping](/blog/iso-27001-soc-2-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](/blog/iso-27001-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](/blog/iso-27001-a-5-16-identity-management) governs the identities the credentials belong to, and [A.5.15 Access control](/blog/iso-27001-a-5-15-access-control) sets the policy for who is granted access in the first place. [A.8.24 Use of cryptography](/blog/iso-27001-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](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies).

*Part of Truvo's control-by-control ISO 27001 reference series, anchored by the [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies).*

### Get your credential and secrets handling audit-ready

Truvo designs and evidences how authentication information is managed as part of an effective security program, on cloud or on-prem.

[Book Your Strategy Call](/contact-us)

 

## 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.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is ISO 27001 A.5.17?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What evidence satisfies A.5.17?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How is A.5.17 different from A.8.5?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How is A.5.17 different from A.5.16 identity management?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Does A.5.17 require a secrets manager?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What password rules does A.5.17 expect?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    }
  ]
}