ISO 27001 A.8.5: Establish secure authentication

What A.8.5 requires in practice

A.8.5 asks for secure authentication technologies and procedures, chosen according to the access restrictions in place and the organisation's access-control policy. Authentication is how a system gains reasonable confidence that a user, device or service is who it claims to be. The stronger the consequence of a wrong identity, the stronger the method needs to be.

In practice an organisation decides which methods suit which systems, sets up the technology accordingly and defines the procedures around it. Those procedures include how credentials are first issued, how they are reset or recovered, how repeated failures are handled and when sessions end. A strong login that can be defeated through a weak reset process does not meet the intent.

Outputs are a reasoned choice of methods per system, working configuration and evidence from real use. The control does not require multi-factor methods everywhere, or any named product. One way Sterling's teams record the reasoning is a short table of systems against methods, which is a working method and not a stated obligation.

Match the method to the access being protected

Consider the sensitivity of information, the actions permitted and the consequences of a false identity claim. Privileged administration and routine access to low-sensitivity information may need different assurance. Multi-factor authentication can strengthen the process, but the factors, implementation and recovery arrangements must be suitable for the use.

Authentication and authorisation remain separate. Successfully proving an identity does not mean that identity should have broad permissions. Coordinate the method with information access restrictions and privileged access so stronger login does not become an excuse for excessive rights.

Protect enrolment and recovery

A method is only useful if the correct person or entity receives it. Establish how credentials or factors are enrolled, changed and replaced. A lost device, inaccessible factor or changed telephone number needs a controlled support route. The process should verify the request appropriately rather than waive protection whenever a user reports urgency.

Recovery arrangements also need to remain usable. If authorised users cannot recover access through a practical route, they may share accounts or create informal workarounds. Test the process with relevant users, including accessibility needs and remote support conditions. Appropriate alternatives should preserve assurance rather than silently introduce an easier bypass.

Why secure authentication matters to the business

Stolen or guessed credentials remain one of the commonest ways into business systems. Once an attacker is logged in, many other controls treat them as a legitimate user. Customers and insurers therefore ask pointed questions about how access is verified, and a weak answer can delay contracts or raise cost. Good authentication is also visible to staff: sensible methods make secure behaviour easy, while clumsy ones push people towards shortcuts. Matching strength to risk keeps effort proportionate, with the strongest checks reserved for the systems that matter most. For auditors, authentication is simple to test live, so a gap in recovery or session handling is usually found early and weighs on confidence in the wider access arrangements.

How to implement A.8.5

Work from the systems and the consequence of a wrong identity, not from a single favourite technology. Document the reasoning briefly, so that a later change of system or supplier does not quietly weaken a decision that was made for good reasons.

1. List the systems and group them by sensitivity, including administrator routes, remote access and customer-facing portals.
2. Choose an authentication method for each group and note why it is proportionate to the risk, including where stronger checks are used only for sensitive actions.
3. Design enrolment and recovery with as much care as the login, so a help-desk request cannot become the easy way in.
4. Set rules for failed attempts, session length and re-checking before sensitive actions, and test they behave as intended.
5. Bring stray applications into the common arrangement, or record the compensating measure where that is not possible.
6. Cover service and automated identities, which need a defined method and an owner even though no person types a password.
7. Test the whole journey with designated accounts, from enrolment through to recovery and ending a session.

Illustrative IT example: a strong login with a weak reset

Illustrative BPO example: one application outside the common login

A hypothetical BPO business introduces a central sign-in service for its main systems. A smaller reporting application retains a separate local login, and staff assume that the organisation's authentication policy automatically applies to it. That application can export sensitive customer information.

The team inventories the actual access routes and evaluates how the reporting application should meet the required assurance. It tests the approved route and checks whether an unintended alternative remains available. The decision includes ownership of any limitation and necessary treatment. The example shows why central deployment is not proof that every relevant application has the same protection.

Control failed attempts and active sessions

Login processes should resist inappropriate repeated attempts without creating unnecessary disclosure or unacceptable disruption. Error messages should not reveal more sensitive detail than needed. Relevant events need suitable records and evaluation so suspicious activity can prompt action, rather than simply accumulate in a log.

Consider what happens after successful login. Inactive or excessively long sessions can extend exposure, especially on shared devices or in higher-risk locations. Set suitable session behaviour for the application and use. The standard does not provide one universal inactivity period, and a restrictive setting should be evaluated for both security and operational effects.

Strengthen authentication decisions and evidence

Common nonconformities with A.8.5

Authentication findings often sit in the edges around a sound main login.

• Strong login methods on the main portal, but password reset handled by a process that anyone can talk their way through.
• One or two applications outside the common arrangement, using weaker methods with no recorded decision.
• Sessions that remain open indefinitely on shared or unattended equipment.
• Administrator and remote access routes protected no more strongly than ordinary access.
• Default or shared credentials left in use on systems and devices.