ISO/IEC 27001:2022 · derived mapping target
A.8.5Secure authentication
Use authentication methods and technologies, such as multi-factor authentication, that match the sensitivity of what is being protected. Stronger authentication blocks the most common account attacks.
Mapping at a glance
A.8.5Secure authenticationISO/IEC 27001:2022
RCF-0064Strong authentication (MFA)Identity & Access Management · PolicyRCF-0065Strong authentication (MFA)Identity & Access Management · ProcessRCF-0066Strong authentication (MFA)Identity & Access Management · TechnicalRCF-0075SSO & federationIdentity & Access Management · TechnicalRCF-0078Password policyIdentity & Access Management · Technical
A.8.5 is covered by 11 Sekit CSF controls. +6 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0064Strong authentication (MFA) · PolicysupportsThis policy facet requires a second authentication factor for email, the identity platform, remote access and every system holding important data, the written commitment A.8.5 asks for.RCF-0065Strong authentication (MFA) · ProcesssupportsThe process facet enrolls every user in MFA on every in-scope system and tracks coverage so exceptions and forgotten accounts do not persist.RCF-0066Strong authentication (MFA) · TechnicalsupportsThe technical facet enforces MFA in system configuration so sign-in without a second factor is technically impossible, including for legacy protocols and API access.RCF-0075SSO & federation · TechnicalsupportsSSO federation routes critical applications through the central identity provider instead of local accounts, so authentication strength is set once and applied everywhere A.8.5 covers.RCF-0078Password policy · TechnicalsupportsPassword rules are enforced in system configuration so weak passwords are rejected by the identity provider and key applications, not merely discouraged on paper.RCF-0081Session management · TechnicalsupportsAutomatic screen lock and session timeout are enforced centrally on every device, protecting an already-authenticated session the way A.8.5 expects.RCF-0084Remote access · TechnicalsupportsThe remote-access facet restricts connections to encrypted channels on enrolled devices only, one layer of the authentication perimeter A.8.5 expects for remote access.RCF-0138API security · TechnicalsupportsAPI endpoints enforce authentication and per-endpoint authorization technically, extending A.8.5's secure-authentication requirement beyond human sign-in to machine-to-machine access.RCF-0186Zero Trust network access · TechnicalsupportsConditional access checks identity, MFA and device compliance at every sign-in regardless of origin, a stronger authentication posture than a password check alone.RCF-0189VPN management · TechnicalsupportsVPN access requires MFA, current protocols and encryption, applying A.8.5's authentication standard to the remote-access channel specifically.RCF-0336Cloud IAM · TechnicalsupportsCloud access enforces MFA for everyone and role-based permissions instead of standing admin rights, carrying A.8.5's authentication requirement into cloud environments.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
MFA enrollment evidence
The proof that a second verification step (beyond the password) is required to access important systems.
Password policy and manager
The company's password rules (length, complexity, expiry) and whether a password manager is used, plus how they are technically enforced.
From the Sekit evidence catalog
In practice
Secure authentication is the control SMEs get most right on paper and most wrong in coverage. MFA is enforced for email and the identity provider, but a handful of systems, the accounting software, a legacy VPN appliance, a vendor portal, still allow single-factor sign-in because nobody circled back after the initial rollout. Password complexity is enforced by the identity provider, yet a few service accounts and shared logins were created before the policy existed and were never rotated onto MFA. The gap is never the main system, it is always the one system everyone forgot to check.
Common gaps
MFA is enforced for the identity provider and email, but a legacy system or vendor portal still accepts single-factor sign-in.
Service accounts and shared logins predate the MFA rollout and were never re-enrolled, leaving a standing authentication gap.
Session timeout settings are configured on managed devices but not enforced on personal devices used for remote access.
Questions your auditor will ask
Is MFA required on every system, or only the main ones?
Every in-scope system, including legacy protocols and API access, technically requires a second factor; sign-in without it is blocked, not merely discouraged.
How is a weak password stopped in practice?
The identity provider and key applications reject passwords that fail the length and complexity rules at the point of creation.
What happens if a device left unlocked is stolen from an office?
Automatic screen lock and session timeout are enforced centrally on every company device, and users cannot disable them.
Does remote access rely on a shared password or something stronger?
Remote connections require MFA over an encrypted VPN or zero-trust service restricted to enrolled company devices.
Where regulation demands it
NIS2 Article 21 requires multi-factor or continuous authentication solutions (11.7) built on a defined authentication approach (11.6).
ENS op.acc.5 requires a defined authentication mechanism for external users, which secure authentication for remote and third-party access satisfies.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.5?”
Also via MCP, free with account