Authentication information

Plain-language summary

Controlling how passwords, PINs, tokens, keys and other secrets are issued, delivered, reset and protected, and telling people clearly how to look after their own, so authentication information proves identity instead of becoming the weak point.

What the clause is really asking

Stolen or guessed credentials remain one of the commonest ways attackers get in. This control asks for a defined process governing how secrets are handed out and looked after, plus clear guidance to staff on how to treat their own. The process side covers generating temporary credentials securely and forcing a change at first use, delivering them by a secure channel, verifying identity before a reset, changing vendor defaults, and never storing secrets in plain text. The user side covers keeping secrets secret, not sharing or reusing them, changing them immediately if compromise is suspected, and using a password manager. Password rules should reflect current practice — length over complexity, screening against known-breached passwords, change on compromise rather than on a fixed calendar, as NIST SP 800-63B recommends — with multi-factor authentication wherever it is available. The common misunderstanding is that only staff passwords count. API keys, service account passwords, Wi-Fi keys, certificates and shared admin credentials are authentication information too. Under POPIA section 19, weak or shared credentials are hard to defend as reasonable measures after a breach.

What auditors look for

Auditors ask for the authentication procedure and compare it with the password and MFA configuration of the directory and key cloud services. They ask the service desk how a caller's identity is verified before a password reset and how new starters receive initial credentials. They look for credentials in plain text — scripts, spreadsheets, shared documents, notes on monitors. They check MFA coverage, especially for email, remote access and administrators. They ask who knows the shared admin passwords and when those were last changed. The hard question: if this administrator left today, which secrets would you have to change, and where are they listed?

Typical evidence

Authentication information procedure covering issue, delivery, reset, change and storage; password and MFA configuration settings; MFA coverage report; service desk identity verification procedure; approved password manager or secrets vault; register of shared and privileged credentials with rotation records; user guidance on handling credentials; records of default credentials changed.

How to comply — recommendations

Write a one-page procedure for how credentials are issued, delivered, reset and stored, and a half-page user guide on handling them. Configure the directory for long passphrases, breached-password screening and lockout, and enforce MFA on email, remote access, cloud services and every administrator account. Give staff an approved password manager. Move shared and service credentials, API keys and certificates into a secrets vault, each with an owner and a rotation date. Require the service desk to verify identity before any reset. Change default credentials on every new device. Rotate shared secrets whenever someone with access leaves.

Common nonconformities

Passwords and API keys stored in plain text in scripts or spreadsheets; shared administrator credentials not changed after staff departures; no identity verification before password resets; the same initial password issued to all new starters; MFA missing on email, remote access or administrator accounts; vendor default credentials unchanged; no user guidance on handling credentials.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.