--- title: "ISO 27001 Annex A 5.17: authentication information, audit-ready" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-17-authentication-information published: 2023-02-24 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.5.17 Authentication information" journeyStage: implementation --- # ISO 27001 Annex A 5.17: authentication information, audit-ready ## Key takeaways ISO 27001 Annex A 5.17 asks you to manage passwords, keys, tokens and biometrics as a lifecycle: controlled issuance and resets, clear user obligations and technical enforcement. Skip forced 90-day rotation in favour of length, breach screening and MFA. Engineer the evidence so audit sampling becomes an export. - **Scope** — Passwords, keys, tokens and biometrics all count as authentication information, and the control manages them through issuance, user obligations and technical enforcement across their whole lifecycle. - **Rotation** — Neither the NCSC nor NIST SP 800-63B supports arbitrary periodic expiry. Use length, breach-list screening, lockout and MFA, and force a change only on evidence of compromise. - **Resets** — Every reset needs an agreed identity check, such as a callback, video call or manager confirmation, recorded in the ticket, with the new secret never sent in clear-text email. - **Evidence** — Auditors sample recent joiners, reset tickets, identity provider settings and leaver lists. Six evidence items, from policy section to offboarding timestamps, answer that sampling. The security questionnaire asks whether MFA covers every remote and admin account. Your honest answer is "mostly", and the deal waits while someone builds a spreadsheet. ISO 27001 Annex A 5.17 is the control behind that question. An auditor will test it with service desk tickets, identity provider settings and HR's leaver list. This guide is for security managers, IT heads and compliance leads at 25–250-person firms heading for certification or a surveillance audit. It covers what the control requires, how to issue, reset and retire credentials, and how to let your identity provider produce the evidence. ## What does ISO 27001:2022 Annex A 5.17 authentication information require? ISO/IEC 27001:2022 Annex A 5.17 authentication information requires you to manage every secret (passwords, keys, tokens, biometrics) through its whole life. The control has three layers: a controlled process for issuing and replacing credentials, clear duties for the people who hold them, and technical settings that make weak choices impossible, not just discouraged. Each layer maps to practice you probably have in part already: - **Controlled issuance and replacement.** Verify identity first, deliver secrets safely, kill vendor defaults and log significant events. - **User obligations.** Staff keep secrets private, report suspected compromise, choose them well and never reuse one across services. - **Technical enforcement.** Systems reject weak choices outright, so compliance never depends on memory or goodwill. Stolen and guessed credentials are one of the commonest ways attackers get in. The routes repeat. A help desk resets for anyone who sounds plausible, a firewall still runs on its factory login, or a password is reused from a breached consumer site. The commercial exposure is just as direct. MFA coverage is now a standing question on cyber insurance proposals and enterprise security questionnaires, and a weak answer moves premiums or stalls deals. One takeover of an admin or finance mailbox can mean regulatory notification, client disclosure and an invoice-fraud loss in the same week. For a firm already on a modern identity platform, the work is largely configuration plus a service desk procedure: days of effort, not weeks. ## How does A.5.17 fit with A.5.16, A.5.18 and A.8.5? ISO 27001 2022 Annex A 5.17 authentication information sits in the middle of an identity triad. A.5.16 governs the identities credentials attach to, A.5.18 governs the access rights those identities carry, and A.8.5 governs the mechanics of the login itself. Auditors test A.5.16, A.5.17 and A.5.18 as one lifecycle, so put them in place together. Each neighbour owns a different question: - **A.5.16 (identity management)** decides which identities exist, so every credential has an owner. - **A.5.18 (access rights)** decides what each identity can reach once it holds a working credential. - **A.8.5 (secure authentication)** governs the login mechanics and inherits the result of this control. The boundary is the secret itself. As a preventive control, A.5.17 covers how a credential is issued, held, reset and retired, so an attacker never acquires or guesses a working one. Run the three as one project with one owner. A single joiner ticket can then show the identity created, rights approved, first credential generated and MFA enrolled. That one ticket is evidence for all three controls. ## How do you manage ISO 27001 Annex A authentication information securely? Manage authentication information by issuing system-generated, unique, single-use credentials that force a change at first login. Send them by a different channel from the username, and replace every vendor default before go-live. Sending a secret by plain email, or issuing a shared starter password, defeats the whole lifecycle. Treat issuance as four steps your identity provider can perform for you: 1. **Generate, don't choose.** The system creates a unique, single-use first credential and forces a fresh password at first use. 2. **Split the channels.** Send the secret by a route different from the username, and have the recipient confirm it arrived. 3. **Replace defaults as a build step.** Every new device, appliance or SaaS tenancy has its shipped admin login replaced or disabled before go-live. Put it on the provisioning checklist. 4. **Log significant events.** Record issuance, resets and privileged changes in an approved tool, with the log kept confidential. Shrink the number of secrets before you manage them. Put every app you can behind single sign-on (SSO), and issue a company password manager for the rest. Switch on multi-factor authentication (MFA) for anything remote, cloud-hosted or administrative. Three pitfalls undo these steps. Temporary passwords go out by plain email, often with the username in the same message. A shared starter password stays in use because nothing forces a change. Factory logins stay live on firewalls, printers and admin consoles months after installation. A factory login still live on a firewall is a credential nobody is managing. ## How do you handle credential resets securely under ISO 27001 A.5.17? Put an identity check in front of every reset: a callback to a known number, a video call, or confirmation from the requester's manager. Then record that the check happened in the ticket. Never send the new secret in clear-text email. Reset fraud is a social-engineering staple. Agree the method with whoever runs IT support, in writing, and build it into the ticket: 1. **Hold the reset.** Nothing changes until the requester is verified. 2. **Verify by an agreed route.** Call back on a number already on record, never one the caller gives you. Or use video, or get the requester's manager to confirm. 3. **Record the check.** Method, verifier and time go into ticket fields. 4. **Deliver safely.** The new secret is single-use, sent apart from the username, and forces a change at first login. The [ICO guidance on passwords in online services](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/passwords-in-online-services/) recommends time-limiting password reset credentials and never sending passwords by email, even temporary ones. It is written for online services, but the logic carries to staff resets. A reset link or code should expire quickly, and a secret should never sit in an inbox in clear text. Manager confirmation is only as strong as its channel. Ask through contact details in the directory, not by replying to the requester's own message. The commonest failure is a help desk that resets on trust, with no check at all. The next is a check written into the procedure that never reaches the tickets. As far as an auditor can tell, it didn't happen. ## Should you still force 90-day password rotation, and what replaces it? No. The NCSC recommends organisations do not force regular password expiry. NIST SP 800-63B says systems should not require periodic changes, but must force one on evidence of compromise. Set length, screening against breached passwords, lockout and MFA at platform level, and reserve forced changes for suspected compromise. The [NCSC guidance on regular password expiry](https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry) explains why: a forced new password is often easy to work out from the old one, and more likely to be written down. The more often people must change passwords, the more exposed the organisation becomes. The [NIST SP 800-63B Digital Identity Guidelines](https://pages.nist.gov/800-63-3/sp800-63b.html) take the same position from the verifier's side. Forced 90-day rotation doesn't harden passwords. It teaches people to add a digit. Configure quality at the platform instead. These settings replace rotation: - **Minimum length**, favouring long passphrases over baroque complexity rules. - **Breach-list screening**, rejecting common, leaked and service-related passwords, as the ICO guidance recommends. - **No reuse** of previous passwords. - **Lockout** after repeated failed attempts. - **Masked entry** on every sign-in field. - **MFA** for remote, cloud and admin access. Storage is the other half. Anything you build should keep passwords as salted, one-way hashes using a current algorithm such as PBKDF2 or bcrypt, and throttle consecutive failed attempts. For vendors, get confirmation that they do the same. Skipping breach screening means the corporate password may be the one leaked from a consumer site. Home-grown systems that store passwords unencrypted, or hashed with obsolete unsalted algorithms, fail the storage test. At the other extreme, 30-day rotation and baroque complexity rules generate lockouts, support calls and worse passwords. Auditors increasingly read them as legacy habit, not rigour. ## Do you need a standalone password policy, and what about your people? No. At 25 to 250 staff, a credential section inside the access control policy satisfies the control. That section should cover how credentials are issued, what staff must and must not do with them, and which technical settings back that up. Employment terms, awareness training and offboarding then close the people loop. Under the ISO 27001 authentication requirements, auditors test three things: the rules exist, someone senior approved them, and they match what your systems enforce. A separate password policy is a mid-market habit, and it is a second document to keep in step with the identity provider. A 25-person firm can hold all of this in a couple of pages. A 250-person firm adds detail on exceptions and ownership, not another document. The people loop closes with three artefacts: - **Employment terms** stating credential confidentiality obligations. The 2022 control expects them there, so check your contracts actually say so. - **Awareness training** covering credential hygiene: keep secrets private, report suspected compromise, never reuse a password across services. - **Offboarding** that revokes accounts and recovers hardware tokens on the leaver's last day. Leavers are the weak point to watch. Revocation that waits for a monthly tidy-up can leave a departed employee's account live for weeks. Tokens that never come back are still live credentials. Tie revocation to the HR leave date instead. ## How do you automate A.5.17 with GRC engineering? Engineer credential management so it evidences itself. A scheduled job compares your identity provider's user list against MFA enrolment and flags drift the day it appears. HR joiner and leaver events trigger one-time credentials and same-day revocation. Pipeline scans catch factory logins, and mandatory fields in the service desk workflow capture reset verification. Each engineered control leaves its evidence behind as a by-product: - **MFA drift monitor.** A dated coverage report replaces the manual census, and the exceptions list stays current. - **HR-driven lifecycle.** Issuance and revocation timestamps line up with HR dates without anyone compiling them. - **Pipeline default-credential checks.** Provisioning automation and periodic scans test new infrastructure for factory logins, turning a checklist promise into a verifiable control. - **Breach-exposure feeds.** Domain-monitoring services alert when staff credentials appear in public dumps. The alert opens a ticket, forces a reset and logs the loop. - **Mandatory verification fields.** The service desk cannot complete a reset until the identity-check field is filled, so the evidence exists because the process ran. The commercial upside lands at the questionnaire. When an insurer or enterprise customer asks about MFA coverage, you answer with a dashboard export instead of a week of spreadsheet archaeology. Governance stays human. Setting the credential rules, approving MFA exceptions and owning the authentication standard is judgement work, which sits naturally with a Fractional CISO. The monitors, HR triggers and pipeline checks are what GRC engineering builds. | Control area | Manual approach | Engineered approach | What the auditor receives | | --- | --- | --- | --- | | MFA coverage | Periodic census of users against enrolment | Scheduled comparison of user list and MFA enrolment | Dated dashboard export with exceptions | | Joiners and leavers | Ticket raised by hand, account removed at the next tidy-up | HR event triggers one-time credentials and same-day revocation | Timestamps matching HR dates | | Default credentials | Checklist item someone may skip | Pipeline checks and periodic scans for factory logins | Scan results per device | | Breach exposure | Discovered when an attacker uses the password | Monitoring alerts feed forced resets | Ticket trail from alert to closure | | Reset verification | Verbal trust, note optional | Mandatory identity-check field | Completed field on every sampled ticket | ## What goes in the ISO 27001 Annex A 5.17 audit evidence pack? The evidence pack holds six items. They are the approved credential policy section, identity provider settings exports, MFA reports with justified exceptions, the reset procedure with sampled tickets, and provisioning checklists showing defaults replaced. The sixth is people records: employment terms, training and offboarding checklists with revocation times that match HR leave dates. Credibility sits in the detail of each item: 1. **Policy section:** current approval, a date and a named approver. 2. **Identity provider exports:** length rules, breach-list screening, lockout and forced first-use change. Screenshots work at this scale when tenant and date are visible. 3. **MFA reports:** remote, cloud and admin populations, with every exception listed, justified and signed off. 4. **Reset tickets:** the identity check recorded, not just described in the procedure. 5. **Provisioning checklists:** defaults replaced, with dates against specific devices and tenancies. 6. **People records:** employment terms citing credential obligations, completed training, and offboarding checklists with revocation timestamps matching HR leave dates. Most of the pack is the output of the engineered controls in the table above, so it needs collecting, not compiling. A pack built from system exports refreshes on demand. A hand-built pack ages the day it is finished. Two details catch people out. An MFA exception without a sign-off reads as an oversight. A revocation time that trails the HR leave date invites a question about the gap. ## How will the Stage 2 audit test A.5.17, and what grades as a major? Auditors trace a few recent joiners' first credentials and pull two or three reset tickets to check the identity check was recorded. They inspect identity provider settings directly and compare HR's leaver list with account status. Unprotected stored passwords, unchecked resets or privileged remote access without MFA grade major; isolated lapses grade minor. Expect these questions in the room: - Someone rings support claiming to be locked out. What happens before they receive a new password? - Show the settings that stop a password like Summer2026!, and prove they apply to every system, not just the main directory. - Which accounts have MFA, which do not, and who signed off the exceptions? - You installed this appliance in May. When was its factory login changed? - This person left last month. When exactly did their credentials stop working, and where is the token they held? Each question maps to one item in the evidence pack. The password question reaches furthest: the rules must also hold on secondary systems such as VPNs and SaaS admin consoles. Grading follows certification-body practice, not the standard's text. A single undocumented reset or one stale exception grades minor. The same lapse across several tickets reads as a pattern and adds up to a major. Run your own sample before the auditor does: - Trace three recent joiners' first credentials from generation to delivery. - Read the verification field on three recent reset tickets. - Compare HR's leaver list for the last quarter with account status. - Re-read the MFA exceptions list for stale or unsigned entries. With the lifecycle engineered, the sampling exercise stops being a scramble and becomes an export. The Stage 2 conversation then shifts from defending your process to showing it. ## Frequently asked questions ### Does Annex A 5.17 make MFA mandatory? The standard never uses the word. But auditors, insurers and enterprise customers all treat MFA as the baseline for remote access, cloud services and admin accounts. Where a legacy system cannot support it, put the account on the exceptions list with a named approver and a review date. Without that record, the gap looks like an oversight rather than a decision. ### How is A.5.17 different from the 2013 password controls? A.5.17 merges three older controls covering allocation, user responsibilities and password systems into a single lifecycle. It also adds an expectation that significant credential events are logged. If your existing documents still carry three separate sections, fold them into one credential section and point its logging line at your approved tool. ### When must a leaver's credentials stop working under A.5.17? By the end of their last day at the latest. Disabling the account may not end sessions already open on phones and apps, so revoke active sessions in the same step. If the leaver knew the password for a shared account, change it too: a departure is one of the few times a forced change is still right. ### Do hardware tokens count as authentication information under A.5.17? Yes. The control covers passwords, keys, tokens and biometrics, so a hardware token is a credential to log at issue and recover at offboarding. If the device does not come back, disable its registration in the identity provider so the missing token cannot authenticate anyone. Record both steps on the leaver's offboarding checklist. ### Is Annex A 5.17 a preventive control, and which security properties does it protect? Yes. Verified resets, forced first-use changes, blocked breach-list passwords and protected storage all stop an attacker getting or guessing a working credential. It protects confidentiality, integrity and availability, because a stolen credential lets an intruder read, change or take down whatever the account touches.