A.8.5
Secure authentication
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Implement secure authentication technologies and procedures based on access restrictions and risk.
Points of focus
- Enforce MFA across workforce identity and all admin/production access paths
- Prefer phishing-resistant factors (hardware keys, platform authenticators) for privileged and infrastructure access
- Ban shared or generic credentials for any production or admin system
- Set password and session policies based on current guidance (length over forced complexity, breach-list screening, reasonable session timeouts) rather than outdated rules
Implementation notes
Centralize authentication through a single identity provider wherever possible, and enforce MFA as a tenant-wide policy rather than leaving it optional per user. For privileged and infrastructure access — cloud console admin, database admin, CI/CD deployment — require phishing-resistant factors (FIDO2/WebAuthn hardware keys or platform authenticators) rather than SMS or app-based one-time codes, which remain vulnerable to real-time phishing and SIM-swap attacks. Treat any system that authenticates outside the primary IdP (a legacy admin tool, a third-party vendor console, a break-glass path) as a separate control surface requiring its own MFA and access review, since it won't show up in the main IdP export. Eliminate shared credentials for production systems entirely — where automation needs an identity, provision a dedicated service account or use short-lived, workload-based credentials instead of a static shared secret passed between engineers. For password policy, follow current guidance (length over forced complexity, screening against known-breached password lists, reasonable lockout/rate-limiting) rather than legacy rules like forced 90-day rotation, which current standards no longer recommend and which auditors increasingly flag as outdated when applied without justification.
Audit tip: Export the MFA enforcement report directly from your IdP rather than describing policy in prose — auditors want to see enrollment percentage and factor type, and any system that authenticates outside the IdP needs its own evidence.
Evidence auditors typically request:
- IdP configuration export showing MFA enforcement scope and factor types by group
- Admin console/infrastructure access list showing phishing-resistant factor enrollment for privileged accounts
- Password policy configuration (length, breach-list screening, lockout/rate-limiting) exported from the identity provider or application
- Inventory confirming no shared credentials exist for production systems
Common gaps
- MFA is enforced for the corporate IdP login but not for a legacy admin panel that authenticates separately from SSO
- Privileged infrastructure accounts use SMS-based one-time codes, which are phishable, while the policy document claims phishing-resistant MFA everywhere
- A shared "deploy" account with a static password is still used by the on-call rotation because individual accounts were never provisioned for the CI/CD system
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.8.5 | This control |
| SOC 2 | CC6.1, CC6.6 | CC6.1 and CC6.6 cover authentication and boundary protection; auditors typically request the same IdP MFA export for both frameworks, so aligning evidence collection saves duplicate effort. |
| GDPR | Article 32 | Article 32(1) calls for technical measures appropriate to risk — strong authentication on systems processing personal data is one of the most concrete, auditor-legible ways to demonstrate this article in practice. |
| HIPAA | 164.312(d) | 164.312(d) — Person or Entity Authentication — is a required (not addressable) specification, meaning HIPAA-covered systems handling ePHI cannot skip authentication controls the way some other safeguards allow exceptions. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.5)