Secure authentication

Plain-language summary

Making sure the way people and systems prove who they are is strong enough for what they are accessing — multi-factor authentication where the risk calls for it, log-on processes that resist guessing and phishing, and sessions that end when they should.

What the clause is really asking

Attackers increasingly log in rather than break in: in Sophos's State of Ransomware in South Africa 2026, 85% of the South African organisations hit by ransomware said the attack was the same event as their most significant identity attack of the year, against a global average of 67%. The control asks you to choose authentication methods proportionate to the classification of the information and the risk of the access — MFA for remote access, cloud services, email and anything privileged — and to make the log-on process itself secure: no hint whether the username or the password was wrong, limits on repeated failed attempts, passwords never displayed or sent in clear text, failed and successful log-ons recorded, inactive sessions closed. The common misunderstanding is that MFA is the finish line. Push-notification MFA can be defeated by fatigue attacks, where the attacker triggers prompt after prompt until a tired user taps approve; number matching, limits on prompts and phishing-resistant methods such as FIDO2 security keys or passkeys close that gap. Note the split: 5.17 governs how passwords and other authentication information are issued and protected; this control governs the mechanism.

What auditors look for

Auditors ask for the authentication standard — which systems require which method — and then test it. They pull the MFA registration report from the identity provider and look for users not enrolled, service accounts excluded and conditional-access exceptions that quietly became permanent. They check that legacy authentication protocols are blocked, because those bypass MFA. They ask how the VPN, remote desktop, ERP and payroll system authenticate, since these often sit outside single sign-on. They look at lockout settings and session timeouts. The hard question: if an attacker had a user's password right now, what stops them — and show me the sign-in log that proves it.

Typical evidence

Authentication standard mapping systems to required methods; MFA enrolment and enforcement reports; conditional-access or sign-in policy configuration; list of exclusions with approver and review date; evidence that legacy authentication is blocked; account lockout and session timeout settings; sign-in logs showing failed and successful attempts; alerts for risky or anomalous sign-ins.

How to comply — recommendations

Write a one-page authentication standard: MFA for every user on email, cloud services and remote access; phishing-resistant methods for administrators; what applies to service accounts and shared devices. Enforce it centrally through your identity provider's conditional access or security defaults rather than system by system. Block legacy authentication. Turn on number matching and limit push prompts to blunt fatigue attacks, and tell staff that an unexpected MFA prompt is an incident to report, not a nuisance to approve. Bring the ERP, VPN and payroll system under single sign-on where they support it, or set MFA locally where they do not. Review the exclusions list monthly; every exception needs an owner and an expiry date.

Common nonconformities

MFA not enforced for all users or for remote access; administrators using the same weak MFA method as everyone else; permanent exclusions from conditional access with no review; legacy authentication still enabled; systems outside single sign-on relying on passwords alone; no lockout or brute-force protection; sessions that never time out; failed log-ons not recorded or reviewed.

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.