IAM-009 Authentication Information Management
Description
Authentication credentials, covering passwords, API keys, tokens and certificates, are managed through a defined process. Policies enforce minimum complexity, rotation schedules and prohibition of credential reuse. Credentials are stored using approved cryptographic hashing or protection mechanisms. Default and vendor-supplied credentials are changed before deployment. The external authenticators the service will accept are named on a maintained list with the assurance level each is accepted at, and an authenticator outside that list is refused.
Rationale
Weak or poorly managed credentials are among the most exploited attack vectors, and credential policy reduces brute force, credential theft and default-password exploitation. The accepted-authenticator list covers the identities the organisation does not issue: where customers or partners sign in with an identity from elsewhere, the strength of that sign-in is decided by whoever issued it, so accepting an authenticator without deciding what assurance it carries hands that decision away. APP-008 carries secret storage and scanning in code, and IAM-010 carries the non-human identity lifecycle.
Applicability (9 profiles)
Framework Mappings (14)
| IAM-02 | Credentials Management Policy and Procedures | full |
| IAM-14 | Credentials Management | full |
| IAM-02 | Credentials Management Policy and Procedures | full |
| IAM-14 | Credentials Management | full |
| HIPAA-164.308.a.5.ii.D | Password Management | full |
| HIPAA-164.312.d | Person or Entity Authentication | full |
| 5.17 | Authentication information | full |
| NIS2-CIR-11.6 | Authentication | partial |
| NIS2-CIR-11.7 | Multi-Factor Authentication | informative |
| IA-5 | Authenticator Management | partial |
| IA-5(1) | Authenticator Management | Password-based Authentication | partial |
| IA-5(6) | Authenticator Management | Protection of Authenticators | full |
| IA-6 | Authentication Feedback | partial |
| IA-8(2) | Identification and Authentication (Non-organizational Users) | Acceptance of External Authenticators | full |
Evidence (3)
Password and credential management policy defining minimum complexity, rotation schedules, prohibition of credential reuse, and requirements for approved storage mechanisms.
Example: Password Policy or Credential Management Standard document with explicit settings for minimum length (e.g. ≥14 characters), complexity requirements, rotation interval, reuse prohibition (e.g. last 12 passwords), and approved storage mechanisms (e.g. bcrypt/Argon2 hashing for passwords, vault storage for secrets).
Test: Request the password/credential management policy. Verify: (1) minimum password length is ≥12 characters (check against NIST SP 800-63B or the org's stated standard), (2) reuse prohibition is defined numerically, (3) approved storage mechanisms are specified and exclude plaintext or reversible encryption for passwords, (4) policy was reviewed within the last 12 months.
IdP password policy configuration settings and secrets vault configuration showing enforcement of the credential management policy at the system level.
Example: Okta password policy settings export or Azure AD Password Protection configuration showing minimum length, complexity, and lockout settings; plus HashiCorp Vault or AWS Secrets Manager configuration showing TTL/rotation policies for API keys and service credentials.
Test: Read the authentication policy settings from the identity provider and the rotation settings from the secrets store. Verify: (1) the enforced minimum length and complexity meet or exceed the policy document, (2) reuse prevention is active, (3) every secret in the secrets store carries a rotation schedule, (4) default and vendor-supplied credentials have been changed, evidenced by the deployment record or by a configuration assessment run against the environment, (5) settings enforced only on a subset of the identity population are reported as a gap.
List of the external authenticators the service accepts, with the assurance level each is accepted at and the date of its last review.
Example: Accepted external authenticator list v3, reviewed 2026-07-22
Test: Request the accepted authenticator list. Verify: (1) every external identity provider or authenticator the service will accept appears on it, (2) each entry states the assurance level it is accepted at and the basis for that level, (3) an authentication attempt using an authenticator outside the list is refused, tested against the live service, (4) the list was reviewed within the defined interval, (5) an authenticator removed from the list no longer resolves to an active sign-in path.
Questions (3)
Is a documented credential management policy enforced at system level?
The policy must be enforced at the system level, not just documented. Key settings to confirm: minimum length ≥12 characters, reuse prohibition, and approved hashing/storage for secrets.
How are API keys, tokens, and service credentials stored?
A dedicated secrets vault with access control and audit logging is the expected approach. Credentials committed to version control, even encrypted, represent a significant risk. Plaintext storage in version control is a critical finding.
Is there a maintained list of the external authenticators your service accepts, with the assurance level each is accepted at?
External authenticators are the sign-ins your organisation does not issue: a customer or partner identity provider, a social login, a federated enterprise directory. Answer yes only where the list exists, each entry states an assurance level, and an authenticator outside the list is actually refused by the service rather than merely undocumented.