Management of secret authentication information of users

“Management of secret authentication information of users” is a control you pass or fail based on whether secrets are handled through an intentional, repeatable process rather than tribal knowledge. Clause 9.2.4 focuses on the allocation of secret authentication information and extends explicitly to cloud service credentials and API keys. That scope matters: most control failures happen outside the classic “user password” lane, in long-lived access keys, shared admin credentials, and hard-coded secrets in CI/CD pipelines.

As a Compliance Officer, CCO, or GRC lead, your job is to translate this into operational guardrails the engineering and IT teams can follow without debate. You need clear rules for who can request secrets, who can approve, where secrets can live, how they are distributed, when they must be rotated, and what happens when a user leaves or a key is suspected compromised. You also need evidence that the process is followed consistently, including for third parties and automation identities (service accounts) that interact with cloud environments.

This page gives requirement-level implementation guidance you can drop into a control narrative, then drive into tickets, workflows, and audit-ready artifacts.

Regulatory text

Requirement (excerpt): “The allocation of secret authentication information shall be controlled through a formal management process, including secure management of cloud service credentials and API keys.” ¹

Operator interpretation: you must prove there is a defined process (not ad hoc practice) that governs how secrets are requested, approved, created/issued, stored, distributed, rotated, revoked, and monitored. The “including” phrase removes ambiguity: cloud credentials and API keys are in scope, even if your legacy access control procedures only discuss passwords. ¹

Plain-English interpretation (what the requirement really means)

If a user (human or service identity) can authenticate with a secret, you must manage that secret like a controlled asset:

• No unmanaged issuance. People can’t mint keys “because they need it now” without an approved request path.
• No unmanaged storage. Secrets can’t sit in code, tickets, chat, spreadsheets, personal password managers, or shared drives.
• No unmanaged lifecycle. You need rules and evidence for rotation, revocation, and break-glass access.
• No blind spots for cloud/API access. API keys, access tokens, and cloud access keys require the same rigor as passwords. ¹

Who it applies to

Entity types

• Cloud service providers delivering services where customer data or operations depend on credentialed access.
• Cloud service customers operating workloads in cloud platforms with IAM users, roles, access keys, tokens, and third-party integrations. ¹

Operational context (what’s in scope)

• Human users: admins, developers, support engineers, data analysts, contractors.
• Non-human identities: service accounts, CI/CD runners, workload identities, automation bots.
• Secrets: passwords, MFA recovery codes, API keys, OAuth client secrets, signing keys used for authentication, access tokens where your organization controls issuance/storage, and cloud platform access keys. ¹

What you actually need to do (step-by-step)

1) Define what counts as “secret authentication information”

Create and publish a scoped definition. Include examples your teams actually use: cloud access keys, API keys for third-party services, PATs, database passwords, and CI/CD secrets. Tie the definition to handling rules (where it may be stored, how it is transmitted, and required rotation/revocation events). ¹

2) Establish a formal allocation workflow (request → approve → issue)

Document and operationalize:

• Request criteria: business justification, system/service name, environment, required permissions, and intended duration/conditions.
• Approvals: data/system owner approval plus security/IAM approval for privileged scopes.
• Issuance controls: secrets are generated by the platform (vault/IAM) where possible; avoid user-chosen secrets for high-privilege access.
• Traceability: every issued secret maps to an identity, owner, and system, with a unique record ID. ¹

Practical implementation note: the fastest audit win is a single intake path (service catalog or ticket type) that forces the minimum fields and links approvals to issuance.

3) Centralize storage and distribution

Control requirement becomes hard to defend if secrets exist in many places.

• System of record: adopt an enterprise secrets manager/vault as the default store for application and automation secrets.
• No plaintext transport: prohibit sending secrets in email, chat, tickets, and docs; require one-time reveal links or vault-based retrieval.
• Access controls: restrict read access to the smallest set of identities; separate duties for secret administration vs. secret consumption where feasible.
• Third party handling: if a third party needs access, issue dedicated credentials with scoped permissions; prohibit shared accounts. ¹

4) Enforce rotation and revocation triggers

Your process should define rotation rules and event-driven triggers:

• Event-driven rotation: rotate on suspected compromise, credential exposure, role change, admin access grants, and third-party offboarding.
• Offboarding revocation: disable accounts, revoke tokens, delete or deactivate access keys, and rotate shared integration secrets on departure.
• Service account lifecycle: require owners, renewal/attestation, and decommission steps for automation identities. ¹

Avoid rigid promises you can’t consistently meet. Instead, define rotation “based on risk and technical feasibility” and then show that you rotate on clear triggers and for sensitive classes of secrets.

5) Detect and remediate secret sprawl (code, CI/CD, endpoints)

A “formal process” must include controls to find secrets created outside the process:

• Scan repositories and build logs for secrets.
• Monitor for new cloud access keys and unexpected API key creation.
• Quarantine and revoke exposed secrets and document the incident handling steps.
• Add preventative controls: pre-commit hooks, CI checks, and policy-as-code for IAM key creation. ¹

6) Make it auditable: logging and review

You need an audit trail that a reviewer can follow without guesswork:

• Logs of secret creation, access (read), update/rotation, and deletion.
• Periodic access reviews for privileged secrets and shared integrations.
• Exceptions process with time-bounded approval and compensating controls. ¹

Where Daydream fits (without changing your stack)

Most teams can write the policy but struggle to prove execution across cloud accounts, DevOps tooling, and third parties. Daydream helps by turning the requirement into an evidence checklist, mapping each system that can issue secrets (cloud IAM, vault, CI/CD, third-party platforms) to the artifacts auditors request, and tracking exceptions and remediation work in one place.

Required evidence and artifacts to retain

Keep these artifacts in an audit-ready package aligned to the lifecycle:

Policy and standards

• Secret authentication information policy/standard defining scope and handling rules.
• Credential/API key management procedure describing request/approval/issuance/storage/rotation/revocation. ¹

Operational records

• Samples of approved requests and approvals for new secrets (human and service).
• Vault/secrets manager inventory export showing owners, paths/names, access controls, and last rotation metadata (where available).
• Cloud IAM logs showing creation/deletion of access keys and tokens (sampled).
• Offboarding records showing revocation actions tied to HR/IT tickets.
• Exception register for cases where rotation/storage requirements could not be met, with approvals and compensating controls. ¹

Monitoring and assurance

• Evidence of secret scanning (reports, alerts, and remediation tickets).
• Periodic access review results for privileged credentials and high-impact integrations. ¹

Common exam/audit questions and hangups

Auditors and assessors typically press on these points:

• “Show me the formal process.” They want a documented workflow plus examples of real requests completed through it. ¹
• “How do you manage API keys in third-party SaaS?” Expect to explain issuance, storage location, and ownership.
• “How do you know secrets aren’t in source control?” They’ll ask for scanning evidence and response actions.
• “How do you rotate and revoke?” They want triggers, proof of completion, and clarity on who owns the step.
• “What about break-glass?” They will accept emergency access if you have tight controls and retrospective review, but they will reject “shared admin password in a safe” without logs.

Frequent implementation mistakes (and how to avoid them)

1. Only covering employee passwords. Fix: explicitly include cloud credentials, API keys, and tokens in scope and procedures. ¹
2. Secrets in tickets for convenience. Fix: block the pattern by policy, train the service desk, and provide a vault-based alternative that is faster than copy/paste.
3. Shared credentials for third parties. Fix: issue dedicated identities, time-bound access, and require offboarding revocation steps tied to contract end or access expiry.
4. No owner for service accounts. Fix: require an accountable owner (team + named role) and a renewal/attestation checkpoint.
5. Rotation written down but not executed. Fix: start with the most critical secrets, automate rotation where possible, and track exceptions with management sign-off.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, the risk exposure is straightforward: unmanaged secrets increase the likelihood of unauthorized access, persistent compromise via long-lived keys, and uncontrolled third-party access paths. For cloud customers and providers, API keys and cloud credentials are high-impact because they often bypass interactive controls and can be used from anywhere.

Practical execution plan (30/60/90)

First 30 days (stabilize and stop the bleeding)

• Publish the definition of secret authentication information and the “no plaintext sharing” rule.
• Inventory where secrets exist today (vaults, CI/CD, cloud IAM access keys, third-party admin consoles).
• Stand up a single request path for new secrets with mandatory fields and approvals.
• Identify the highest-risk secrets (admin cloud keys, production SaaS admin keys, CI/CD deployment credentials) and move them into the system of record.

Next 60 days (make it consistent and measurable)

• Implement standardized issuance patterns: service accounts for apps, named users for humans, dedicated third-party accounts.
• Turn on secret scanning for repos and CI logs; create a documented playbook for revocation and rotation after exposure.
• Implement offboarding hooks: ensure identity disablement and secret revocation steps are in the same workflow.
• Start periodic reviews for privileged secrets and sensitive integrations; document results and remediation.

By 90 days (audit-ready operations)

• Automate rotation for the classes of secrets your tools support; define exception handling for those that cannot rotate automatically.
• Build an evidence pack template: request samples, logs, inventories, and review outputs.
• Run an internal “tabletop audit” by sampling secrets from each environment and proving end-to-end control from request through revocation.
• If you use Daydream, align each secret-bearing system to the requirement and attach recurring evidence tasks so this stays current without heroics.

Frequently Asked Questions

Does this requirement apply to service accounts and automation, or only human users?

It applies to both if they authenticate with secrets. ISO/IEC 27017 Clause 9.2.4 explicitly includes cloud service credentials and API keys, which commonly belong to non-human identities. ¹

Are access tokens “secret authentication information”?

If the token grants access and your organization issues, stores, or distributes it, treat it as secret authentication information. Manage it through the same controlled allocation, storage, and revocation process described in Clause 9.2.4. ¹

We can’t rotate some third-party SaaS API keys automatically. Is that a failure?

Not automatically, but it becomes a failure if you have no formal process and no proof of control. Document rotation expectations, track keys in an inventory with an owner, rotate on defined triggers, and manage exceptions with approvals and compensating controls. ¹

Can we store secrets in our ticketing system if access is restricted?

That is difficult to defend because ticket systems are designed for collaboration, not secret custody, and copies persist. A safer pattern is to store secrets in a vault and reference the vault path in the ticket, with access controlled through IAM. ¹

What evidence do auditors ask for most often?

They ask for the documented process plus proof it is followed: request/approval records, vault inventory and access controls, and logs showing issuance, rotation, and revocation for sampled credentials. ¹

How do we handle emergency “break-glass” credentials under this requirement?

Treat break-glass as a controlled exception with restricted storage, strict access logging, short-lived access where possible, and after-action review. Document the workflow so it still qualifies as a formal management process. ¹

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services