IAM-009 Authentication Information Management
Description
Authentication credentials (passwords, API keys, tokens, 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.
Rationale
Weak or poorly managed credentials are among the most exploited attack vectors. Credential management policies reduce the risk of brute force, credential theft, and default-password exploitation.
Framework Mappings (4)
| IAM-02 | Credentials Management Policy and Procedures | full |
| IAM-14 | Credentials Management | full |
| 5.17 | Authentication information | full |
| IA-5 | Authenticator Management | full |
Evidence (2)
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: Query IdP password policy settings (e.g. Okta GET /api/v1/policies?type=PASSWORD). Verify: (1) minimum length and complexity match or exceed the policy document, (2) password history enforcement is active, (3) for API keys and secrets, query the secrets manager for rotation configuration — verify all secrets have a rotation schedule configured, (4) check that default/vendor credentials have been changed by reviewing the initial setup log or running a scan with a tool such as ScoutSuite or Prowler.
Questions (2)
Is a credential management policy in place that defines minimum password complexity, rotation schedules, prohibition of credential reuse, and approved storage mechanisms?
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.