ISO 27001 A.8.5: Secure Authentication

ISO 27001 A.8.5 requires that secure authentication technologies and procedures are implemented based on how sensitive the information and system are, so that anyone logging in proves who they are before they reach anything. It is a Technological control (A.8), and teams most often get flagged on weak log-on mechanics: no multi-factor authentication on an internet-facing path, or a password policy still built on the composition rules NIST retired.

What is ISO 27001 A.8.5?

A.8.5 Secure authentication governs the mechanisms and procedures that verify a claimed identity before access is granted. In the words of ISO/IEC 27001:2022, Annex A, the control title is Secure authentication. The intent, as described in ISO/IEC 27001:2022, Annex A, is that authentication technologies and procedures are selected and configured according to the classification and risk of the information being reached, and strengthened beyond a single password where that risk warrants it.

A.8.5 is the mechanism control, and two related controls are easy to confuse with it. A.5.15 Access control sets the policy for who is allowed access and on what basis; A.8.5 secures the act of logging in once that policy says a person qualifies. A.5.17 Authentication information governs the lifecycle of the secrets themselves, how passwords, keys, and tokens are allocated, stored, and reset. A.8.5 governs the log-on procedure that puts those secrets to work: how many factors, how failed attempts are handled, and how the credential is protected while it travels.

How do you implement A.8.5?

Implement A.8.5 by hardening the log-on procedure itself, in a sequence a team can follow regardless of where the systems live:

1. Require multi-factor authentication on every internet-facing and privileged path. MFA combines at least two independent factors: something known (a password or PIN), something held (a hardware key or authenticator app), or something inherent (a biometric). This is the single most citable authentication decision in a security review. Where a system genuinely cannot support MFA, document the exception and compensating controls rather than leaving the gap silent (covered in the evidence section below).
2. Set a password and passphrase policy aligned to NIST SP 800-63B. The current guidance is an 8-character minimum when MFA is enforced, or 15 characters without it. Drop forced composition rules (mandatory uppercase, lowercase, number, special character) and drop routine forced rotation. Check new and changed passwords against a breached-password list instead, and reject known-compromised values. Length and screening protect better than complexity rules, which push people toward predictable values such as Password1!.
3. Design the log-on procedure to give nothing away. A failed login should not reveal whether the username or the password was wrong, and it should not display a prior successful or failed attempt in a way that helps an attacker. Successful authentication should establish a session with a defined idle and absolute timeout.
4. Rate-limit and lock out on repeated failures. Throttle repeated failed attempts and enforce an account lockout or an increasing back-off so credential-stuffing and brute-force attempts are slowed and made visible. Feed failed-authentication events into monitoring so a spike triggers an alert.
5. Protect authentication information in transit and at rest. Authentication traffic travels over TLS end to end so credentials never cross the network in cleartext. Stored passwords are salted and hashed with a strong, purpose-built algorithm; reversible encryption and plain-text storage both fall short of the control. This is where A.8.5 touches the credential handling that A.5.17 Authentication information owns in full.
6. Prefer strong, phishing-resistant factors where the risk warrants it. For high-value access, hardware security keys or platform authenticators (FIDO2, WebAuthn) resist phishing in a way that SMS and one-time codes do not. Match the factor strength to the sensitivity of what is behind the login.

Steps 1, 3, and 5 implement meaningfully differently in cloud and on-prem environments. The two subsections below cover each.

In cloud environments

Cloud environments implement A.8.5 through an identity provider that centralizes authentication and enforces the log-on rules in one place:

• Identity provider MFA (Okta, Entra ID, Google Workspace, or equivalent) enforces multi-factor authentication across every connected application from a single policy.
• Single sign-on with SCIM provisioning routes every application login through the IdP, so one authentication policy and one audit log cover the estate instead of per-app password stores.
• Conditional access policies raise or lower the authentication requirement by signal: device posture, network location, user risk score, or the sensitivity of the target application. A high-risk sign-in can be stepped up to a stronger factor or blocked.
• Managed password policy and breached-credential detection in the IdP enforce the NIST-aligned length and screening rules and flag credentials found in known breach corpuses.
• TLS everywhere for authentication traffic, with the IdP and application endpoints terminating modern TLS, protects credentials in transit by default.
• Phishing-resistant factors (FIDO2 security keys, platform passkeys) configured as the required factor for administrators and sensitive applications.

On-prem / self-hosted

On-prem environments implement A.8.5 through the directory and access-path components directly, producing their own evidence. The SOC 2 access control on-prem guide covers the full implementation; the shape is:

• Active Directory Group Policy enforcing the password length, lockout threshold, and idle-timeout settings across domain-joined systems, exported from secpol.msc or gpresult /r as evidence.
• VPN with certificate plus MFA at the perimeter. A per-user device certificate combined with a PIN and a TOTP token means the strongest authentication happens at the front door, which can then be documented as the deliberate reason MFA is not re-prompted on every internal system.
• LDAPS (LDAP over TLS) for any application authenticating against the directory, so credentials never cross the network in cleartext.
• Local password policy on systems that do not join the domain (network appliances, certain databases, legacy applications), enforced to the same organizational standard with the gap documented where a system cannot meet it.
• Account lockout and failed-logon logging on directory and local systems, feeding a syslog or SIEM pipeline so repeated failures are alertable.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.5?

Evidence for A.8.5 is the record that authentication is configured to the risk, enforced, and protected: a configuration artifact showing the mechanism exists, paired with the policy that sets the standard. Many teams automate these exports through GRC engineering, wiring the IdP and directory configurations into a pipeline that refreshes the evidence on a schedule instead of screenshotting before each audit.

How does A.8.5 map to SOC 2?

A.8.5 is a Full overlap with SOC 2 CC6.1. Both govern the authentication mechanisms, unique identifiers, and password controls that restrict logical access, so the same evidence serves both audits without adaptation.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including the other access-control controls (A.5.15, A.5.16, A.5.17, A.5.18, A.8.3) that CC6.1 also touches, and where existing SOC 2 work transfers to ISO 27001.

Related controls

A.8.5 secures the act of logging in, and it depends on the access-control controls around it. A.5.15 Access control sets the policy for who may access what, which A.8.5 then enforces at the log-on step. A.5.16 Identity management governs how the identities being authenticated are created and managed, and A.5.17 Authentication information governs the allocation, storage, and reset of the credentials A.8.5 puts to work. A.8.2 Privileged access rights applies stronger authentication specifically to elevated permissions. All four fall within the Technological and access-control scope covered by the ISO 27001 certification guide.

Part of Truvo's control-by-control ISO 27001 reference series, anchored by the ISO 27001 certification guide.

Frequently Asked Questions

What is ISO 27001 A.8.5?

ISO 27001 A.8.5 is the Annex A control titled Secure authentication, in the Technological theme. It requires that authentication technologies and log-on procedures are selected and configured according to the sensitivity and risk of the information being accessed, so that identity is verified before access is granted. It covers multi-factor authentication, secure log-on procedures, password and passphrase quality, rate-limiting and lockout, and protecting authentication information in transit and at rest.

What evidence satisfies A.8.5?

Typical A.8.5 evidence includes MFA configuration exports, password policy settings from the identity provider or an Active Directory GPO export, an authentication policy that cites NIST SP 800-63B, conditional access or access-path records, failed-login and lockout logs with alerting, TLS and credential-storage configuration, and documented MFA exception records with compensating controls for any system that cannot enforce it.

What password policy does A.8.5 expect?

A.8.5 does not name a specific standard, but NIST SP 800-63B is the most commonly adopted basis. Its current guidance is an 8-character minimum with MFA enforced, or 15 characters without, with forced composition rules and routine forced rotation dropped, and new passwords screened against a breached-password list. Citing NIST SP 800-63B in the policy gives the auditor confidence the rules are deliberate rather than arbitrary.

How is A.8.5 different from A.5.17 and A.5.15?

A.5.15 Access control sets the policy for who is allowed access and on what basis. A.5.17 Authentication information governs the lifecycle of the secrets themselves, how passwords, keys, and tokens are allocated, stored, and reset. A.8.5 Secure authentication governs the log-on procedure that verifies identity: how many factors are required, how failed attempts are handled, and how the credential is protected while it travels. The three are complementary controls.

How do you implement A.8.5 in the cloud versus on-prem?

Cloud implementations centralize authentication in an identity provider: IdP-enforced MFA, single sign-on with SCIM, conditional access by device and risk, managed password policy with breached-credential detection, and phishing-resistant factors such as FIDO2 keys. On-prem implementations reach the same outcomes through Active Directory Group Policy, a VPN with certificate plus MFA at the perimeter, LDAPS for directory authentication, and local password policy on systems that cannot join the domain. The mechanisms differ; the log-on outcomes are equivalent.

Does A.8.5 require MFA on every system?

No. A.8.5 requires authentication strength proportional to risk, and MFA is expected on internet-facing and privileged paths. Where a system genuinely cannot support MFA, the correct approach is a documented risk acceptance in the register with compensating controls such as a longer password requirement and IP allowlisting, so the exception is a deliberate, evidenced decision rather than a silent gap.