Annex A 5.17: Authentication Information

Annex a 5.17: authentication information requirement means you must control the full lifecycle of authentication secrets (passwords, MFA seeds, API keys, private keys, tokens) so they are issued securely, stored and transmitted safely, changed or revoked promptly, and never exposed in logs or shared channels. Operationalize it with an authentication information standard, system-by-system ownership, and recurring evidence capture mapped to ISO/IEC 27001:2022 Annex A 5.17. ¹

Key takeaways:

• Define what “authentication information” includes, then assign owners and handling rules per system and third party connection.
• Build lifecycle controls: creation, distribution, storage, rotation, recovery, revocation, and monitoring for exposure.
• Keep audit-ready evidence: standards, inventories, configs, access reviews, rotation logs, and incident records tied to 5.17.

Annex A 5.17 is one of those controls that auditors treat as “simple” but operators experience as messy. The scope is broader than user passwords. It includes any credential or secret that proves identity: service account passwords, SSH keys, API keys, signing keys, database credentials, OAuth client secrets, break-glass credentials, and MFA enrollment artifacts. If any of those live in spreadsheets, tickets, chat threads, source code, or unmanaged password vaults, you have a practical 5.17 gap even if you “require SSO.”

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate 5.17 into a small set of non-negotiable rules, then drive adoption through system ownership and measurable evidence. This page gives you requirement-level implementation guidance you can hand to IT, Security, Engineering, and IAM without re-litigating fundamentals. The aim is operational control: fewer credential leaks, fewer privilege escalations, cleaner offboarding, and an assessment package that ties policies to real configurations and recurring proof of operation. ¹

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.17 implementation expectation (Authentication Information).” ¹

Operator interpretation: You must protect authentication information from creation through retirement. That means you define handling requirements, restrict access, prevent disclosure, and ensure credentials are changed/withdrawn when no longer needed. Assessors will expect documented rules plus evidence that those rules are enforced in real systems (identity provider, endpoints, servers, CI/CD, cloud, and third party integrations). ¹

Plain-English interpretation (what 5.17 requires)

Annex a 5.17: authentication information requirement boils down to this:

1. Know what counts as authentication information. Include human credentials and non-human secrets (machine-to-machine).
2. Control who can issue, view, or reset it. Reduce administrators, require approvals for high-risk access, and separate duties where feasible.
3. Store and transmit it securely. No plaintext storage, no unencrypted transfer, no embedding in code or images, no pasting into tickets.
4. Rotate and revoke it reliably. Especially after offboarding, role changes, suspected exposure, or third party termination.
5. Detect and respond to exposure. Have scanning, alerting, and an incident playbook for leaked credentials.

Who it applies to

Entity scope: Any organization running an ISMS aligned to ISO/IEC 27001:2022, including service organizations providing services to customers. ²

Operational scope (where it shows up):

• Workforce identities: employees, contractors, and temporary staff in your IdP/SSO, endpoints, and SaaS tools.
• Privileged access: admins, root accounts, break-glass access, domain admins, cloud console admins.
• Non-human identities: service accounts, bots, CI/CD runners, integration users.
• Cryptographic material used for authentication: SSH keys, signing keys used to authenticate services, client certificates where used as identity.
• Third party access paths: vendor support portals, MSP access, customer tenant admin access, partner API integrations. Use “third party” as the umbrella because the same credential hygiene applies.

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

Use this sequence to operationalize quickly and create audit-ready outputs.

Step 1: Define “Authentication Information Standard” (one page plus appendices)

Write a standard that answers:

• In-scope secrets: passwords, MFA seeds/recovery codes, API keys, private keys, tokens, client secrets, service account credentials.
• Approved storage: enterprise password manager and/or secrets manager; disallow spreadsheets, wikis, tickets, chat logs.
• Transmission rules: no sending secrets via email/chat; use vault sharing with access expiry; use one-time secret links if needed.
• Minimum controls by category:
  • Human accounts: SSO/MFA expectations, password rules for local accounts.
  • Privileged accounts: separate admin identities, break-glass storage, session logging expectations.
  • Non-human secrets: secrets manager, scoped permissions, rotation triggers.
• Rotation/revocation triggers: role change, termination, suspected compromise, third party offboarding, system compromise, code leak.

Map the standard directly to Annex A 5.17 and make it part of your controlled document set. ¹

Step 2: Build an inventory of authentication stores and secret types

You cannot prove control without an inventory. Create a register with:

• System/app name and owner
• Secret types used (password, API key, SSH key, token, certificate)
• Where stored (IdP, secrets manager, password vault, config file, database)
• Who can access/view/reset
• Rotation method (manual, automated) and revocation method
• Third party touchpoints (who, why, how authenticated)

Practical tip: start with your highest-risk platforms: cloud provider, source code repos, CI/CD, customer production access paths, and support tooling.

Step 3: Assign ownership and implement handling controls per system

For each system in the inventory, require the system owner to attest to these controls:

Creation/issuance

• Strong generation (no human-chosen API keys; use system-generated secrets).
• Documented joiner process for privileged access and service accounts.
• Approval required for high-privilege secrets and third party support accounts.

Storage

• Put non-human secrets in a secrets manager; stop storing in environment variables in plain text files or shared folders.
• Put shared admin credentials (where unavoidable) in a password vault with named user access and audit logs.

Distribution

• Use vault-based sharing. Time-bound access for contractors and third parties.
• For break-glass, keep sealed access with dual control where feasible (two-person approval) and log every retrieval.

Rotation and revocation

• Ensure offboarding triggers remove access and revoke keys/tokens.
• Rotate after suspected exposure, vendor termination, and major incidents.
• For long-lived credentials (SSH keys, static API keys), define a rotation cadence and enforce it with reminders and evidence (your cadence can be risk-based; document the rationale).

Logging and exposure prevention

• Ensure logs do not capture secrets (request headers, query strings, debug logs).
• Add secret scanning in source control to catch committed keys.
• Monitor for leaked credentials and have a standard revoke-and-replace procedure.

Step 4: Establish operating rhythm and recurring evidence capture

Annex A 5.17 frequently fails on “we do it, but can’t prove it.” Set up recurring evidence:

• Quarterly or periodic access review for privileged and shared vault items
• Periodic review of service accounts and non-human identities
• Ticketed rotation/revocation events with timestamps and approvers
• Exceptions register for any legacy systems that cannot comply yet

This is where Daydream fits naturally: track the control statement, map it to each in-scope system, assign owners, and schedule evidence requests so 5.17 stays continuously provable instead of rebuilt at audit time. ¹

Required evidence and artifacts to retain

Keep these artifacts in an “Annex A 5.17 evidence folder” with clear naming and dates:

Governance

• Authentication Information Standard (approved, versioned)
• Scope statement listing what you treat as authentication information
• Exceptions register and risk acceptances (with compensating controls)

Operational

• Inventory/register of systems and secret types, with owners
• Screenshots/exports of vault/secrets manager access controls (who can view, who can administer)
• Configuration evidence: IdP/MFA settings for privileged roles, password vault sharing policies, secrets manager policies
• Rotation/revocation records (tickets, change logs, key revocation logs)
• Offboarding records showing timely deprovisioning for privileged accounts
• Secure SDLC evidence: secret scanning configuration and sample alerts/tickets

Assurance

• Access review outputs (privileged and shared secrets)
• Incident records for credential exposure (even if “near miss”), including revoke/rotate actions and lessons learned

Common exam/audit questions and hangups

Auditors tend to probe the same weak points:

1. “Define authentication information.” If you only talk about passwords, they will ask about API keys, tokens, service accounts, and SSH keys.
2. “Show me where secrets are stored.” Expect sampling: one production database credential, one CI/CD secret, one third party integration secret.
3. “Who can view secrets in plaintext?” Vault access controls and audit logs matter.
4. “What happens at termination?” They will want evidence that access is removed and secrets are revoked where shared or embedded.
5. “How do you prevent secrets in code and logs?” Demonstrate scanning and logging redaction, not just policy language.
6. “Prove operation.” A policy without rotation events, access reviews, or change records reads as shelfware.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails 5.17	Fix
Treating 5.17 as “password policy only”	Non-human secrets are the common blind spot	Expand scope and inventory: service accounts, API keys, tokens, SSH keys
Secrets shared in tickets/chat “temporarily”	Creates uncontrolled copies and audit gaps	Require vault-based sharing and one-time secret workflows
No clear owner for each secret store	No one can attest, rotate, or revoke reliably	Assign system owners in the register and require periodic attestations
Rotation is “as needed” with no record	Hard to prove and easy to defer	Define rotation triggers, track events via tickets and logs
Offboarding removes SSO but leaves API keys alive	Credentials persist outside IdP	Add offboarding checklist items for tokens/keys and integrations
Exceptions become permanent	Legacy sprawl grows	Set expiry dates for exceptions and require compensating controls

Enforcement context and risk implications

No public enforcement cases are provided in the supplied source catalog, so this page does not cite specific actions.

Risk-wise, 5.17 failures are high-impact because authentication information is a direct path to unauthorized access. Common outcomes include account takeover, lateral movement via service accounts, undetected third party access persistence after termination, and secret sprawl that defeats your incident containment. Treat 5.17 as a control that reduces both breach likelihood and breach blast radius. ¹

Practical execution plan (30/60/90-day)

Use this as an operator plan. Timelines are guidance; adjust to your environment.

First 30 days (Immediate)

• Publish the Authentication Information Standard and get formal approval.
• Stand up the inventory/register and identify system owners.
• Identify “stop the bleeding” channels: tickets, chat, shared drives, code repos. Issue a directive: no secrets in these locations; move to approved vaults.
• Pick your evidence approach: what screenshots/exports/logs you will collect and how often.

By 60 days (Near-term)

• Onboard priority systems to approved storage (password vault/secrets manager) and remove shared plaintext secrets.
• Implement secret scanning in source code repos and create a triage workflow for findings.
• Implement a consistent joiner/mover/leaver workflow for privileged access and third party access.
• Run the first access review for privileged accounts and shared secrets; remediate findings.

By 90 days (Stabilize and make auditable)

• Require each system owner to provide one full lifecycle proof: creation, storage, access control, rotation/revocation, and logging/redaction.
• Mature revocation: ensure third party offboarding includes disabling accounts and rotating any shared or embedded credentials.
• Formalize exception management: documented compensating controls and expiry dates.
• Put recurring evidence capture on a calendar and track it in Daydream so 5.17 stays current between audits. ¹

Frequently Asked Questions

What exactly counts as “authentication information” under Annex A 5.17?

Treat any secret or token used to prove identity as in scope, including passwords, API keys, tokens, SSH keys, and service account credentials. Document your definition and apply it consistently across systems. ¹

Do we need a secrets manager to meet annex a 5.17: authentication information requirement?

ISO 27001 does not mandate a specific tool, but you must show controlled storage, access, and rotation. If you cannot prevent plaintext sprawl with existing tooling, a secrets manager or enterprise vault becomes the practical control. ¹

How do we handle shared admin accounts that a third party uses for support?

Avoid shared accounts where possible. If you cannot, store credentials in a vault with named-user access, approvals, and retrieval logs, and rotate after each engagement or when personnel change. ¹

What evidence will an auditor accept to prove rotation and revocation?

Change tickets, vault audit logs, key management logs, and system logs showing revocation events are all useful. Pair them with your standard so the assessor can see the rule and the proof of operation. ¹

Is MFA covered by 5.17 or a different control?

MFA is often addressed across multiple controls, but 5.17 still applies to MFA “authentication information” such as enrollment artifacts and recovery codes. Treat recovery codes like secrets: restricted access, secure storage, and replacement if exposed. ¹

We found secrets in a Git repo. What’s the compliant response?

Revoke and replace the exposed credentials, remove them from code, and check logs and deployments for reuse. Record the incident, root cause, and prevention step (for example, secret scanning and developer guidance) as evidence of control operation. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview