ISO/IEC 27001:2022 · derived mapping target
A.5.17Authentication information
Manage passwords, keys and other authentication secrets securely, and guide users in choosing and protecting them. Strong, well-handled credentials are a first line of defense.
Mapping at a glance
A.5.17Authentication informationISO/IEC 27001:2022
RCF-0064Strong authentication (MFA)Identity & Access Management · PolicyRCF-0065Strong authentication (MFA)Identity & Access Management · ProcessRCF-0076Password policyIdentity & Access Management · PolicyRCF-0077Password policyIdentity & Access Management · ProcessRCF-0078Password policyIdentity & Access Management · Technical
A.5.17 is covered by 9 Sekit CSF controls. +4 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) · PolicysupportsRequiring a second authentication factor is a control on how authentication itself is verified, one of the concrete safeguards A.5.17 asks organisations to put around credentials.RCF-0065Strong authentication (MFA) · ProcesssupportsTracking MFA enrolment so no account slips through unenrolled turns the MFA requirement into something protecting every credential, not only the ones someone remembered to set up.RCF-0076Password policy · PolicysupportsDocumenting minimum length, no reuse, mandatory password-manager use and shared-credential handling supports A.5.17's authentication information requirement, though credential issuance and non-human secrets are covered by other controls.RCF-0077Password policy · ProcesssupportsGetting every employee onto the password manager is what makes the written password rules real, rather than rules people work around with reused passwords.RCF-0078Password policy · TechnicalsupportsRejecting weak or short passwords in system configuration enforces A.5.17's credential rules technically, closing the gap between what the policy says and what the system allows.RCF-0079Session management · PolicyrelatedSession idle timeouts protect an already-authenticated session rather than the credential itself, a related safeguard that sits next to A.5.17's authentication information controls.RCF-0112Secrets management · PolicysupportsRequiring every password, API key and credential to live in an approved vault supports A.5.17's authentication-information requirement by covering machine secrets, but it does not give users the guidance A.5.17 also requires on choosing and protecting their own credentials.RCF-0113Secrets management · ProcesssupportsIssuing, rotating and revoking credentials through a managed routine, with leavers losing access the day they go, keeps A.5.17's credential-handling requirement current rather than set once.RCF-0114Secrets management · TechnicalsupportsDeploying a vault with per-person access and no credentials embedded in code is the technical control that makes A.5.17's secrets-handling rule enforceable, not only written down.
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
In practice this control comes down to two things working together: a company-wide password manager everyone uses, and MFA enforced on every system that matters rather than only the ones a vendor defaulted to secure. Auditors ask for the password policy and manager evidence and spot-check a few accounts to see whether the identity provider rejects a weak password, not only whether the policy document says it should. The recurring failure is credentials living outside the vault: API keys pasted into a chat channel, or a shared password for a legacy system written down because nobody migrated it.
Common gaps
The password policy requires a manager for everyone, but adoption is inconsistent and several staff still keep passwords in a spreadsheet or browser autofill instead.
API keys and service credentials for a legacy system are hardcoded in a script rather than stored in the approved vault, despite the secrets policy prohibiting it.
MFA is enforced on email and the identity provider but not on a handful of older systems that predate the rollout.
Questions your auditor will ask
Where do employees store their passwords?
Point to the company password manager and confirm employee adoption through usage records, not only the mandate in the password policy.
Is multi-factor authentication required for all accounts with access to sensitive systems?
Show the MFA enrolment evidence covering the identity platform, email and any system holding important business data, and name any documented, time-limited exception.
How are API keys and other non-human credentials protected?
Describe the secrets vault used for API keys and service credentials, with per-person access control and no credentials embedded in code or scripts.
Where regulation demands it
NIS2 art. 11.6 (Authentication) and art. 11.7 (Multi-factor authentication) require the same credential and MFA safeguards A.5.17 asks organizations to enforce.
ENS op.acc.5 (Mecanismo de autenticación, usuarios externos) sets the equivalent baseline for authentication mechanisms.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.17?”
Also via MCP, free with account