ISO 27001 A.5.17: Protect Authentication Information

What A.5.17 requires in practice

Annex A control A.5.17 asks that the allocation and management of authentication information be controlled through a management process. Authentication information is whatever proves identity, such as passwords, tokens, keys or certificates. The control also expects personnel to be advised on how to handle it properly.

There are two strands. The process side covers how secrets are issued, delivered, changed, recovered and withdrawn, so that they reach only the right person and stop working when they should. The people side covers guidance: staff need to know what to protect, what not to share and what to do if a secret may be exposed.

The control does not set password length, rotation or a specific technology; those choices follow the organisation’s risk and rules on access. It also does not stand alone, as it works together with the controls on access rules and secure authentication. What matters is that the lifecycle of credentials is deliberate and people are equipped to protect them.

Secure the issue and recovery routes

Map how an authorised person receives initial authentication information and how replacement is requested. Verify the requester using an appropriate trusted process before issuing replacement material. Recovery should not depend solely on information an impersonator could obtain from a public profile or a compromised mailbox.

Use a delivery method suited to the sensitivity of the credential. Temporary credentials need controlled handling and an appropriate transition to normal use. Avoid putting usable secrets into broadly accessible tickets, shared onboarding spreadsheets or routine email chains. Records should show that the authorised process occurred without unnecessarily retaining the secret itself.

Test support staff’s ability to handle pressure. A caller claiming an urgent executive meeting may seek an exception to verification. Staff need an authorised escalation route that preserves the security decision while addressing the business urgency. A process that only works when callers are patient is unlikely to remain dependable.

Address credentials used by systems

Service secrets can spread through deployment files, administrator notes and integration settings. Identify their accountable owner and the systems that depend on them. Decide where approved storage is needed, who can retrieve or replace the secret and how changes can occur without uncontrolled service interruption.

Plan for compromise and personnel changes. Removing a person’s account may not remove knowledge of a shared or service credential. Consider whether relevant authentication information must change and how the change will be verified. Coordinate this with access-rights removal instead of treating account closure as the end of the task.

Why authentication information matters to the business

Stolen or guessed credentials are among the most common causes of breaches. Even strong technology fails if default passwords stay unchanged, secrets are shared in messages or recovery routes can be abused. A managed process reduces the chance that a credential reaches the wrong hands and limits the harm if it does.

Staff guidance matters just as much. People who understand why a secret must stay private, and who feel able to report a mistake, help the organisation react quickly. For customers and assessors, a clear approach to credentials is one of the most visible signs of mature access practice, and weaknesses here are often found quickly.

How to implement A.5.17

Look at the whole life of a credential, from the moment it is issued to the moment it stops working. Remember that credentials for systems and services need the same care as those used by people, and often get less.

1. List the kinds of authentication information in use, including passwords, keys, tokens and certificates for people and systems.
2. Define how initial secrets are issued and delivered, and require users or owners to replace temporary or default ones.
3. Decide how secrets are recovered or reset, and make sure that route verifies the person properly.
4. Set expectations for storage and sharing, and provide an approved tool or method so staff are not tempted to improvise.
5. Define how credentials are withdrawn or replaced when people leave, suppliers change or exposure is suspected.
6. Give staff short, practical guidance, including how to report a lost or exposed credential without fear of blame.
7. Review the process after incidents and when systems change, adjusting where weaknesses appear.

Illustrative BPO example: an urgent reset request

Illustrative software example: a deployment secret changes hands

A hypothetical software team uses a service credential in a release process. An engineer leaving the team knows the credential, although personal access has been removed. The application owner initially assumes that the departure process is complete.

The team identifies the dependent services and performs a controlled replacement. It checks that the old credential no longer works and that the release process still operates. The lesson is to manage knowledge and use of authentication information, not merely the account record. A managed secret-storage tool may support this approach, but selecting one does not remove the need for ownership.

Help users follow realistic handling rules

Explain which information is personal and must not be shared, how approved shared arrangements work and where suspected exposure is reported. Give users a workable way to manage strong, distinct credentials. Rules that exceed system capabilities or force people into unsafe workarounds should trigger design review.

Do not confuse repeated password changes with complete protection. The 2022 guidance recognises practical problems with unnecessary frequent changes and discusses changes when needed. Determine the organisation’s approach from risk, applicable obligations and current technical design. Suspected compromise requires an effective response rather than waiting for a calendar date.

Evidence without exposing secrets

Common nonconformities with A.5.17

Weaknesses usually appear in the less visible parts of the credential life cycle. Assessors usually test this control by talking with staff and examining how credentials are handled in practice.

• Default or initial passwords remain in use on systems or devices after installation.
• Credentials are shared among colleagues or sent in plain messages for convenience.
• The password reset route allows someone to take over an account with little checking.
• Keys, tokens or certificates for systems have no owner and are never replaced or withdrawn.
• Staff have received no guidance about protecting credentials or reporting a suspected exposure.