Use of secret authentication information

ISO/IEC 27017 Clause 9.3.1 requires you to make users follow your organization’s rules for handling secret authentication information (passwords, API keys, MFA factors) specifically when accessing cloud services. To operationalize it, convert your “rules” into enforceable technical controls (SSO/MFA, password policy, secrets handling) plus training, monitoring, and audit evidence. ¹

Key takeaways:

• “Require users to follow practices” means policy + enforcement + proof, not a PDF in a portal.
• Scope includes workforce users and non-human identities (service accounts, automation) accessing cloud services.
• Your audit win condition is evidence: configured controls, access logs, exceptions, and user acknowledgments.

This requirement is deceptively short. Auditors and cloud customers interpret it as: you must define how secret authentication information is created, stored, used, shared, and rotated, then you must make those practices real in day-to-day cloud access. It covers human logins (admins, engineers, support staff) and non-human access (service accounts, CI/CD jobs, API keys) because both rely on “secret” material that can be stolen and reused.

Operationally, most failures come from gaps between intent and enforcement: a password policy that doesn’t apply to cloud consoles because SSO isn’t enabled; API keys stored in chat threads; shared admin accounts; MFA “recommended” instead of required; or exceptions granted without expiry. For a Compliance Officer or GRC lead, the fastest path is to (1) define the practices in one authoritative standard, (2) map each practice to a technical control in your identity provider and cloud platforms, and (3) retain evidence that proves users actually comply.

This page gives you requirement-level implementation guidance you can execute immediately, with specific artifacts to produce and the exam questions to pre-answer. ¹

Regulatory text

Text (excerpt): “Users shall be required to follow the organization's practices in the use of secret authentication information when accessing cloud services.” ¹

What the operator must do

You must do three things, and you need all three to pass a serious audit:

1. Define “organization’s practices” for secret authentication information (SAI) in a controlled document set (policy + standard/procedure).
2. Require compliance by turning those practices into enforceable controls for cloud access (SSO/MFA, password rules, key handling, privileged access).
3. Prove compliance with retained evidence (config screenshots/exports, logs, training/attestation, exception records).

This is a cloud-focused requirement: the practices must apply to access paths into cloud services (cloud consoles, SaaS admin panels, APIs, CLIs, automation). ¹

Plain-English interpretation (what “secret authentication information” covers)

Treat “secret authentication information” as any confidential material that can authenticate a user or process, including:

• Passwords and passphrases
• MFA secrets (seed/QR, recovery codes) and factors where applicable
• API keys, access tokens, client secrets, signing keys used for authentication
• SSH private keys used to access cloud-hosted systems
• Break-glass credentials and emergency access secrets

Your “practices” must address the lifecycle: issuance, storage, transmission, use, rotation, revocation, and disposal. The clause is not satisfied if secrets management is “best effort” or left to team preference. ¹

Who it applies to (entity and operational context)

Entity types

• Cloud Service Providers (CSPs): You must ensure your workforce and operational users follow your SAI practices when administering or delivering cloud services to customers. ¹
• Cloud Service Customers: You must ensure your workforce follows your SAI practices when accessing the cloud services you consume (IaaS, PaaS, SaaS). ¹

Operational contexts to scope explicitly

• Workforce identity access to: cloud provider consoles, SaaS admin portals, CI/CD systems, ticketing systems with production access hooks
• Privileged access: root/admin roles, tenant-wide admin roles, database admin in managed services
• Non-human access: service principals, workload identities, API keys used by apps, pipelines, RPA bots
• Third-party access: consultants, managed service providers, support vendors, auditors with temporary access

A common audit gap is scoping “users” only as employees. Your control story must cover anyone who can authenticate into your cloud environment. ¹

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

Step 1: Write a single “SAI Practices for Cloud Access” standard

Create (or update) a standard that is narrow and enforceable. Minimum topics:

• Approved authentication methods for cloud services (SSO required where supported; local accounts restricted)
• Password requirements where passwords exist (length/complexity rules, reuse, reset process)
• MFA requirements (where mandatory, factor types allowed, recovery process, restrictions on SMS if you set them)
• Secret handling rules: no sharing, no posting in tickets/chat/email, approved vault, approved CI/CD secret stores
• Service account rules: ownership, purpose, non-interactive use, rotation expectations, logging requirements
• Break-glass rules: where stored, who can access, dual control if you require it, post-use review
• Exception process: who approves, compensating controls, expiry, review cadence

Your objective: remove ambiguity so “follow the practices” has one authoritative meaning. ¹

Step 2: Convert practices into technical enforcement

Auditors look for “required,” not “recommended.” Translate policy into configuration:

• Centralize authentication: enforce SSO to cloud consoles and SaaS where feasible; disable or tightly control local accounts.
• Enforce MFA: require MFA for interactive access, with stricter requirements for privileged roles.
• Privileged access management: restrict standing admin rights; require just-in-time elevation or gated workflows if available.
• Secrets management: mandate a secrets vault or approved platform secret store; block plaintext secrets in code repos where you can.
• Access reviews: periodically review accounts with console/API access and privileged permissions; ensure terminated users are removed promptly.

If your cloud service cannot enforce a practice (some SaaS platforms are limited), document the constraint and implement compensating controls (network restrictions, conditional access, enhanced monitoring, reduced privilege). ¹

Step 3: Operationalize onboarding, offboarding, and role changes

Make compliance automatic:

• Joiner process creates the identity in IdP, assigns groups/roles, and enrolls MFA before access is granted.
• Mover process re-evaluates least privilege; remove old roles explicitly.
• Leaver process disables SSO, revokes sessions/tokens where supported, and rotates shared secrets that user could access.

Tie these flows to HR or ticketing triggers so they are consistent and auditable.

Step 4: Train users and collect acknowledgment

You must be able to show that users know the practices:

• Security awareness module focused on password/MFA hygiene and secrets handling for cloud access.
• Targeted admin training for engineers with privileged permissions.
• Attestation or policy acknowledgment tied to onboarding and periodic refresh.

Step 5: Monitor and respond

“Require” also implies detection and correction:

• Alert on: MFA disabled, creation of local console users, creation of new API keys, privileged role assignment, repeated failed logins.
• Review logs for anomalous access and impossible travel events where your tooling supports it.
• Define response steps for suspected credential compromise: revoke sessions, rotate keys, investigate scope, document incident.

Step 6: Manage exceptions like a regulated process

Exceptions are allowed in practice, but they must be controlled:

• Written justification and risk acceptance
• Compensating controls documented
• Explicit expiry date and owner
• Evidence of review and closure

If you use Daydream for third-party due diligence or internal control tracking, treat authentication exceptions as “high-friction” items: require approvals, attach evidence, and schedule automated reminders for expiry and re-review so exceptions do not become permanent. ¹

Required evidence and artifacts to retain

Keep evidence that maps cleanly to the clause language (“users required to follow practices”):

Governance artifacts

• SAI policy/standard for cloud access (approved, versioned, owned)
• Procedures: onboarding/offboarding, MFA reset, service account creation, key rotation, break-glass use
• Exception register with approvals and expiry

Technical evidence

• IdP and cloud/SaaS configuration exports or screenshots showing:
  • MFA required policies
  • SSO enforcement settings
  • Password policy settings (where applicable)
  • Conditional access rules
• Inventory of service accounts and API credentials (owner, system, purpose)
• Logs showing authentication events and admin changes (MFA changes, role assignments, key creation)

People/process evidence

• Training completion records for relevant populations
• Policy acknowledgment records
• Access review records (who reviewed, findings, remediation tickets)

Aim for “re-performable” evidence: a reviewer should be able to trace from policy to control to logs without asking you to interpret tribal knowledge.

Common exam/audit questions and hangups

Expect these, and prep the artifacts above:

• “Show me where your practices are documented for passwords, MFA, and API keys for cloud services.”
• “Prove MFA is required for all users accessing the cloud console.”
• “How do you prevent shared accounts and password sharing?”
• “How do you control and rotate service account credentials?”
• “Show me your break-glass process and evidence it’s reviewed after use.”
• “How do you handle third-party access to your cloud tenant?”
• “What happens when someone fails to follow the practice (example: secret in a ticket)?”

The hangup is usually coverage: one neglected SaaS admin panel with local accounts can undermine the narrative.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only compliance. Fix: implement conditional access and SSO enforcement; treat policy as the “why,” configuration as the “how.”
• Mistake: Ignoring non-human identities. Fix: require ownership, inventory, and documented rotation expectations for service accounts and API keys.
• Mistake: Over-broad admin rights. Fix: reduce standing privilege; document who has tenant admin and why.
• Mistake: Exceptions without expiry. Fix: require expirations and track them in a register with reminders and re-approval workflow.
• Mistake: Secrets in code or tickets. Fix: provide an approved vault and add detection in repositories; train support and engineers on secure sharing patterns.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk standpoint, weak control over secret authentication information increases the chance of account takeover, unauthorized access to cloud resources, and inability to demonstrate due care during audits or customer security reviews. ¹

Practical execution plan (30/60/90)

Use phases rather than calendar promises; move as fast as your environment allows.

First 30 days (Immediate control lift)

• Confirm scope: list cloud services and admin surfaces (IaaS, key SaaS, CI/CD).
• Publish/update the SAI Cloud Access standard (passwords, MFA, secrets, service accounts, exceptions).
• Enforce MFA for cloud console access where supported; restrict local accounts.
• Stand up an exception register and require security approval for any bypass.

Next 60 days (Operational hardening)

• Move major platforms to SSO and conditional access policies.
• Create service account intake workflow: owner, purpose, least privilege, logging.
• Centralize secrets storage into an approved vault/secret store; document approved patterns for CI/CD.
• Implement access review process for privileged roles; track remediation tickets.

By 90 days (Audit-ready evidence)

• Produce an evidence pack: policy, configs, training completion, access review records, exception register, sample logs.
• Run a tabletop test for credential compromise response and document outcomes.
• Validate third-party access controls (time-bound access, MFA, monitoring) and store approvals and termination evidence.

Daydream can help by keeping the evidence pack and exception register in one place, assigning owners, and preserving an audit trail that maps directly to the requirement language. ¹

Frequently Asked Questions

Does this requirement apply to API keys and service accounts, or only employee passwords?

It applies to “secret authentication information,” which includes API keys, tokens, and other secrets used to authenticate, not just passwords. Treat non-human identities as in scope for practices, enforcement, and evidence. ¹

If we have SSO and MFA, are we done?

SSO and MFA address a large part of “requiring” compliance, but you still need documented practices for secrets handling and evidence that users follow them. Auditors also expect controls for service accounts, break-glass access, and exceptions. ¹

How do we handle SaaS tools that can’t enforce our password or MFA standards?

Document the limitation, restrict access paths (for example, SSO-only if possible), and apply compensating controls like reduced privilege and enhanced monitoring. Capture the exception with an owner and expiry. ¹

What evidence is most persuasive to an auditor?

Configuration evidence showing enforcement (MFA/SSO/conditional access) plus logs demonstrating real use, backed by training/attestation and an exception register. The best evidence chain links policy requirement to control setting to observed authentication events. ¹

Do third parties need to follow our practices if they access our cloud environment?

Yes. If a third party authenticates into your cloud services, they are “users” in the operational sense and must follow your practices. Implement this through contract terms, onboarding controls, and time-bound access. ¹

What’s the simplest way to control exceptions without slowing engineering to a halt?

Use a lightweight exception workflow: predefined categories (MFA bypass, local account, legacy integration), required compensating controls, explicit expiry, and a single approval path. Track it in a system like Daydream so evidence, reminders, and ownership do not live in email. ¹

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