Annex A Controls Explained

ISO 27001 Control 5.17: Authentication Information

How to implement control 5.17 by an ISO 27001 Lead Auditor

ISO 27001 Toolkit ISO 27001 in 90 days ← Back to Controls List

Last Updated: 29 July 2026

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

ISO 27001 Control 5.17: Authentication Information
Allocation and management of authentication information shall be controlled by a management process, including advising personnel on appropriate handling of authentication information.
https://www.iso.org/standard/27001

Key Takeaways

5.16 issues the identity, 5.17 governs the secret that proves it, 8.5 is the login itself. Knowing the split tells you where to file your evidence.
The Annex A requirement says nothing about complexity or expiry. Those come from guidance, and you are certified against the standard rather than the guidance.
A policy built on length, deny lists and no routine rotation follows current NCSC advice and satisfies the control. Write the rationale down and it will not be challenged.
The reliable finding on this control is a policy that says one thing and a platform that enforces another. Open both at the same time.
Emailing a new starter their first password fails the control on its own terms. Use an activation link instead; it costs nothing and you already have it.
MFA is the single highest-value action here. Authenticator app as the floor, phishing-resistant methods for administrators.
A system that cannot support MFA is not a failure. Not knowing about it is.
After a compromise, revoke sessions and check forwarding rules and MFA methods. Changing the password alone leaves the attacker where they are.

ISO 27001 Control 5.17: Authentication Information

Introduction

Someone once said to me “Hackers don’t break in, they log in”, which is commonly true, but not entirely. However, this control is, along with others, about how you can secure those logins and be confident you know who is logging in. Control 5.16 ( Identity Management) issues the identity. Control 5.17 governs the secret that proves somebody is legitimately using it. Typically, this is done via the password, the token, the certificate, the fingerprint – or, as is often the case now, a passcode.

In honesty, I think this is the control where the standard shows its age (that and its inability to address AI directly, and its attempt at Cloud Services, but that’s for another page). The supporting guidance still reads like password advice from 2005: mix in some special characters, change it regularly, do not write it down. The NCSC has been telling UK organisations the opposite for years, and NIST reached the same conclusion. Almost every guide to this control simply repeats the older model without noticing the conflict.

So this page does two things. It provides guidance on what 5.17 actually requires, and it shows you how to write a password policy that follows the better guidance without an auditor marking you down for it. That second part is easier than most people expect, and I will come to exactly why.

What control 5.17 actually asks for

The Annex A requirement is short. It asks that the allocation and management of authentication information is controlled by a management process, and that personnel are advised on how to handle it properly. What that means in practice is the following:

A defined process for issuing credentials, replacing them, and revoking them.
Verification of the person before a new, replacement or temporary credential is handed over.
Secure transmission of the credential itself, which rules out the way most organisations actually do it.
Default vendor credentials replaced as soon as anything is installed.
Users told, in terms they will act on, how to look after credentials and what to do if one is exposed.
Systems that enforce whatever quality rules your policy claims to enforce.
Records of significant events in the life of a credential.

Note what is not in there. The requirement says nothing about password length, character composition or expiry intervals. Those all come from the supporting guidance in ISO 27002, which is exactly why you have more freedom here than most people realise. Hold that thought.

Where 5.17 sits among the access controls

Five controls in this family get confused with one another constantly. They certainly confused me in my earlier days of the standard. So, it’s worth being able to say which is which, because auditors ask for different evidence against each.

Control	What it governs	What the auditor asks for
5.15 Access control	The policy layer. Who should be able to reach what, and the rules that govern it.	Your access control policy, and whether it reflects reality.
5.16 Identity management	Who or what an identity belongs to.	Your identity inventory, including service and shared accounts.
5.17 Authentication information	The secret that proves the identity is being used by its owner. How it is created, issued, stored and handled.	How a new starter receives their first credential, and where shared credentials live.
5.18 Access rights	What that identity is permitted to do once authenticated.	Provisioning and revocation records, access review evidence.
8.5 Secure authentication	The act of logging in. The authentication mechanism, failed attempt handling, session behaviour.	Your MFA configuration and how sign-in is technically enforced.

The pairing people find hardest is 5.17 against 8.5 (Secure Authentication). The clean split: 5.17 is about the credential, 8.5 is about the login. Issuing a new starter a one-time password over a secure channel is 5.17 (i.e. don’t post it in the company Slack channel). The tenant configuration that demands a second factor when they sign in is 8.5. Multi-factor authentication touches three controls at once, and it is worth understanding which part lives where: the requirement to use it belongs in your 5.15 policy, the handling of the factors themselves is 5.17, and the enforcement mechanism is 8.5.

In practice, most auditors will not split hairs over the above boundary. But being able to explain it is the difference between sounding like you run the ISMS and sounding like you downloaded it ;-)

The first password problem

Here is the most common failure on this control, and it is sitting in almost every SME I assess…

A new starter joins. Someone in IT creates the account, sets a password, and emails it to the new starter or to their manager. Occasionally it goes into a chat message. Sometimes it is the same base password every time with the year on the end.

That fails the control on its own terms. The standard asks for authentication information to be transmitted over protected channels, and unencrypted email is not one. It also fails on a practical level, because that email will still be sitting in two mailboxes and a sent items folder three years from now.

The fix costs nothing:

Let the platform do it. Microsoft 365 and Google Workspace can both send a time-limited activation or invitation link instead of a password. The user sets their own credential and you never handle a secret at all. This is the best answer and it is already built into what you are paying for.
Split the channel where you must set one. Username by email, password by phone or text. Two channels means an intercepted mailbox is not enough.
Force a change on first use, and make the temporary credential expire if it is not used within a short window.
Never reuse a starter password. If your IT provider issues Welcome2026 to every new joiner, an attacker who works that out has a key to every account created this year.

Trace this for yourself before an auditor does. Pick your most recent starter and find out, honestly, how the credential reached them.

A Cautionary Tale

A couple of years ago I worked with a company of around forty people, including an in-house development team.

One of the developers was dismissed. The reasons were to do with personal conduct rather than anything technical, and it did not end amicably. He left with a considerable grievance.

He also left with knowledge. Some months earlier he had set up an account for a colleague and had chosen the initial password himself. That colleague had never changed it. Nobody had ever checked that they had.

He posted the account name and the password on 4chan.
The attacks began within minutes. Not hours, minutes. There is a standing audience for that sort of post, and a live credential attracts it immediately.

What saved them was that the service alerts fired. Somebody was logging in at eleven o’clock at night to kick the sessions out and shut the account down. That is what this failure actually looks like in practice: not a boardroom incident, but one person at a laptop late in the evening, working out what is still connected.

Here is the part worth sitting with. The leaver process had worked. His own accounts were disabled on the day he left, exactly as they should have been. The company had done that bit properly.
What nobody had considered is that revoking someone’s access does not revoke what they know. He did not need his own account. He needed somebody else’s, and he had handed it to them himself, months earlier, with the best of intentions.

Three things would have stopped it, and all three are free.

Force a password change on first use, as a platform setting rather than an instruction in an email. Had that been switched on, the credential he remembered would have stopped working within a day of him creating it.
Do not let one person choose another person’s initial password. Send an activation link and let the user set their own. Nobody can remember a secret they were never given.
When somebody who issues credentials leaves, rotate the credentials they issued. This is the step almost nobody takes. When an administrator or a developer walks out of the door, the offboarding checklist covers their own access and stops there. It should also cover everything they set up, everything they could reset, and everything they might simply remember.

One last thing, and it is the reason this was a bad night rather than a catastrophe: the alerting worked. Nobody would have known otherwise, because from the outside it was a legitimate account being used with the correct password. Authentication controls tell you who should be getting in. Logging and monitoring are what tell you when something has.

What the guidance says about passwords, and what NCSC actually recommends

This is the part of control 5.17 worth reading carefully, because the two sources pull in opposite directions and nobody tells you what to do about it.

The supporting ISO guidance of ISO 27002 reflects the older model: enforce composition rules, change passwords periodically, do not record them. The NCSC position, arrived at after looking at what people actually do under those rules, is close to the reverse.

The older model	What NCSC recommends instead	Why
Enforce complexity: upper case, lower case, digits, special characters.	Set a minimum length and screen against a deny list of common and breached passwords.	Complexity rules produce predictable coping strategies. Everyone reaches for the same substitutions and the same exclamation mark on the end, so the rules narrow the search space rather than widening it.
Expire passwords every 30, 60 or 90 days.	Do not expire on a schedule. Change immediately on any suspicion of compromise.	Forced rotation makes passwords worse, because people increment rather than rethink. If an attacker has the credential, ninety days is far too long anyway; if they do not, the change achieves nothing.
Users must memorise passwords and never write them down.	Use a password manager as secure storage.	The rule was written before password managers existed. Asking people to memorise unique credentials for forty services guarantees reuse, which is the actual risk.
Leave password choice to the user.	Three random words for anything that has to be memorised.	Longer, more memorable and less predictable than a complex short password. Worth knowing it is a floor rather than a ceiling: cracking dictionaries for common word combinations exist, so add length or a fourth word for high-value credentials, and use the manager to generate everything else.

So how do you depart from the guidance without failing an audit?

This is the question the whole section exists to answer, and the answer is more comfortable than people expect.

I’ll say this until I’m blue in the face, but it’s important: You are certified against ISO 27001, not ISO 27002.

ISO 27002 is guidance on how the controls might be implemented; it is not a set of requirements and you are not audited against it. Any auditor who thinks otherwise and raises a nonconformity against it needs to go back to auditor school.

The Annex A requirement for 5.17 says nothing about complexity or expiry. A password policy built on length, deny lists and no routine rotation satisfies the control completely.

What creates a nonconformity is not departing from ISO 27002, it’s departing from your own policy. If your policy claims twelve characters and your tenant enforces eight, that is a finding, and it is one of the easiest findings in the world to pick up.

Two things make this painless in an audit:

Write the rationale into the policy itself, in a sentence. Something like: this approach follows current NCSC guidance, which advises against complexity requirements and routine expiry on the basis that both reduce password strength in practice.
Reference it in your risk assessment. Then if an auditor does ask why you have no expiry rule, the conversation is about your documented risk decision rather than about an omission, and that is an entirely different conversation.

I have yet to see this challenged when it is written down. I have seen plenty of organisations get written up for a policy that promised complexity rules nobody had configured.

Passcodes and PINs

Your policy will look inconsistent unless it addresses these directly. Somebody will notice that it demands fourteen characters while their laptop unlocks with six digits.

The distinction is that a device-bound PIN, such as Windows Hello, is not a shared secret. It never leaves the device, it is protected by the hardware security module, and it is worthless to anyone without physical possession of that machine. Repeated guessing gets locked out at the hardware level. That is why six digits is a defensible length here and would not be on a web login. Write that reasoning into the policy in a sentence and the apparent contradiction disappears.

For phone and laptop passcodes, enforce through your device management rather than by asking nicely: a minimum of six digits, biometric unlock permitted on top, automatic wipe after a set number of failed attempts, and device encryption on.

Then there are the passcodes nobody thinks of as IT at all. Door entry codes, alarm codes, the key safe. These are shared by definition, offer no individual accountability, and in most businesses I visit have not been changed since installation, which means every leaver for the past six years still knows them. Treat them as shared credentials: record them, give each one a named owner, and change them when somebody leaves.

Multi-factor authentication

If you do one thing on this control, do this one. MFA stops the overwhelming majority of credential attacks, including every attack that depends on a password harvested from somewhere else.

Where to enforce it

Every administrative and privileged account, without exception. This is the one an auditor will check first.
All remote access, including VPN and anything reachable from the internet.
Email, because the mailbox is the reset route into everything else.
Finance systems and anything holding personal data at volume.
Ideally everything else too. At SME scale there is rarely a good reason to stop at a subset.

Not all factors are equal

Factor	Strength	Where it fits
SMS or voice code	Weakest	Vulnerable to SIM swap and interception. Still far better than nothing, so do not let the search for something better leave an account with no second factor at all.
Email code	Weak	Circular if the mailbox is the thing being protected. Avoid for anything important.
Authenticator app code	Reasonable	A sensible baseline for most SME users. Can still be captured by a convincing real-time phishing page.
Push with number matching	Good	Resists the push-bombing tactic where an attacker spams approval prompts until somebody taps accept out of irritation. Enable number matching if your platform offers it.
Passkeys, FIDO2 or hardware keys	Strongest	Phishing-resistant, because the credential is bound to the real site and will not release to a lookalike. Worth the cost for administrators at minimum.

A proportionate position for most small businesses: authenticator app as the floor for everyone, hardware keys or passkeys for anyone holding administrative rights.

What about systems that will not support it?

Every business has at least one. That old line-of-business application, a supplier portal, a piece of finance software that has not been updated since 2019. Some system that just won’t support your policy / controls.

You do not fail the control for having them. You fail it for not knowing about them. Record each one, note why MFA is unavailable, apply what compensating controls you can, and give it a review date:

Restrict access by IP address or source network where the system allows it.
Use a long, unique, manager-generated password, since this is one of the few places where password strength is genuinely carrying the load.
Limit who has an account on it at all.
Raise it with the supplier and record that you did. Repeated requests are themselves evidence of active management.

That list is exactly what the tracker below is for, and it turns an awkward question into a demonstration that you are on top of it.

As always, per my guidance to my coaching clients, you can defend almost anything so long as it’s a conscious decision, risk assessed and tracked!

Authentication and MFA Coverage Tracker Download
This template allows you to track your gaps/coverage. One row per system, covering whether MFA is enforced, for which users, by what method, the compensating controls where it is unavailable, and a review date.

Authentication-and-MFA-Coverage-Tracker Template Download

Password managers at SME scale

A password manager is the only realistic way to have unique credentials across every service, and it answers the old rule about never writing passwords down.

Use a business tier, not personal accounts. The difference that matters is administrative recovery and offboarding. If someone leaves and their vault leaves with them, you have created a new problem rather than solved one.
Protect the manager itself with MFA. It is now the single most valuable target in the business.
Use shared vaults for shared and service credentials, with individual logins so you can see who retrieved what and when. That retrieval log is what makes a shared account defensible.
The master password is the one thing anyone genuinely has to memorise. Four or five random words, not three.

Auditors do not care which product you chose. They care whether it is used consistently, whether the credentials that matter are actually in it rather than in a spreadsheet, and whether a leaver loses access to it on the day they leave.

/patter

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View Details Book a discovery call

Storage and transmission

Worth being honest about scope here. If you buy your systems rather than build them, most of the cryptography in this control is not yours to implement.

For anything you build: passwords are hashed with a current, deliberately slow algorithm and individually salted. Never encrypted in a reversible form, never stored in plain text. If your development team cannot tell you which algorithm is in use, that is the question to ask this week.

For everything you buy: you cannot inspect your SaaS provider’s password storage, so this becomes a supplier assurance question rather than a technical one. It belongs in your due diligence under supplier controls, alongside their certifications and breach-notification commitments.

For transmission, one rule covers most of it: credentials never travel through email, chat or ticket bodies. Those are all searchable, all retained, and all readable by anyone who later gains access to the account. A password pasted into a team channel in 2022 is still sitting there today, fully indexed.

When a credential is compromised

The instinct is to change the password. That is the first step, not the whole response, and the gap between the two is where attackers persist.

Changing a password does not end an active session, and it does not remove anything the attacker set up while they were in. A proper response covers:

Change the credential, and change it anywhere the user admits to having reused it.
Revoke active sessions and refresh tokens. Without this, the attacker stays signed in through the password change.
Check the MFA methods registered on the account. Attackers routinely add their own so they retain access after a reset.
Check for mail forwarding rules and inbox rules. This is the classic persistence trick in a business email compromise, and it is easy to miss because the mailbox looks normal.
Review OAuth grants and application passwords, which survive credential changes by design.
Record the event. That record is your evidence under this control and feeds your incident management process.

If you take one item from that list, take session revocation. It is the step most commonly skipped and the one that most often leaves an attacker still inside an account everybody believes has been secured.

What auditors will look for

As a Lead Auditor, this is broadly the order I would work through 5.17.

1. Trace one new starter’s first credential. Show me how it reached them. If the answer is an email containing a password, we have found something in the first two minutes.

2. Your password policy against your actual platform settings. I will read what the policy claims, then ask to see the tenant configuration. The gap between the two is the most reliable finding on this control.

3. MFA coverage. Not whether you have MFA. Which systems and accounts do not have it, and whether you can name them without going away to check.

4. Where shared and service credentials live. A password manager is a good answer. A spreadsheet is not, and neither is a pinned message.

5. Default credentials. I will ask about the things nobody thinks of as IT: the network switch, the NAS, the door entry system, the printer, the CCTV recorder.

6. The last time a credential was compromised. What you did, in what order, and whether you have a record of it.

Common issues

The policy says twelve characters and the tenant enforces eight. Nobody has ever compared the two documents. Pretty easy to check.
Initial passwords sent by email, frequently the same base password. An own goal, any day.
MFA on all SaaS apps, but not on the VPN, the finance system or the supplier portal.
Expiry still enforced every ninety days, producing a workforce whose passwords differ by one digit each quarter.
Default credentials still live on infrastructure nobody classes as IT. Printers and network kit are the usual offenders.
Shared credentials in a spreadsheet on the file server, often in a folder called IT.
A password reset process weaker than the login it protects. If the helpdesk resets a password on the strength of a phone call and a first name, MFA has been bypassed without anyone attacking anything.
No record of credential events at all, so there is nothing to show for the requirement to keep them.

The self-check

Five questions. Answer them before somebody else does.

How did your most recent new starter receive their first password, and could you evidence it?
Does your platform actually enforce what your password policy claims?
Which of your systems do not have MFA, and can you name them without looking?
Where do your shared and service account credentials live right now?
If an account were compromised tomorrow, would you revoke sessions and check forwarding rules, or just change the password?

Two or more uncomfortable answers means this control needs work before your next audit.

A worked example

The figures below are typical rather than drawn from a single engagement experience of mine. I have put together a composite of what this exercise usually turns up in a business of this size, because a specific instance didn’t readily spring to mind (sorry!).

A 25-person professional services firm on Microsoft 365, with a practice management system, a cloud accounting package and a supplier portal for one large client.

What the review might find

A password policy that specifies twelve characters with complexity rules and ninety-day expiry. If then the tenant was found to be enforcing eight characters with no expiry, there would be a clear discrepency between policy and reality.
MFA enabled for email but not for the VPN or the accounting package.
New starter passwords emailed by the outsourced IT provider, using a common word / format with the current year (i.e. easy to predict or intercept)
Shared credentials for the supplier portal in a spreadsheet on the shared drive without access control (i.e. anyone can access it).
A system that does not support MFA at all, and nobody had recorded that anywhere.
The office network switch and the NAS are both still on vendor default credentials.

What they could change to fix it

Rewrite the policy around a fourteen-character minimum, a deny list, no routine expiry, and a one-line rationale citing NCSC guidance. Then configure the tenant to match it.
Extend MFA to the VPN and the accounting package, and issued hardware keys to the three people with administrative rights. Where MFA isn’t possible, record it.
Switch new starter provisioning to invitation links, so the provider never handles a password again.
Move shared credentials into a business password manager with per-person logins.
Record the system on the authentication tracker with an IP restriction as a compensating control, a note of the supplier request raised, and a six-month review date.
Change the default credentials on the switch and the NAS the same afternoon.

The policy-versus-configuration mismatch is the key thing to focus on here.

How control 5.17 links to other clauses and controls

Control 5.15, Access control. Your access control policy is where the requirement to use MFA is anchored. Without that baseline written down, an auditor has nothing to measure your 5.17 implementation against.
Control 5.16, Identity management. 5.16 establishes who the identity belongs to; 5.17 governs the secret that proves it. The handover of the first credential sits exactly on the boundary, which is why the first password problem belongs to both.
Control 5.18, Access rights. Authentication proves who you are. 5.18 decides what that gets you once you are through the door.
Control 8.5, Secure authentication. The closest neighbour. 5.17 is the credential, 8.5 is the login procedure that consumes it, including how failed attempts and sessions are handled.
Control 8.2, Privileged access rights. The accounts where your strongest authentication belongs, and where an auditor will look hardest.

Frequently asked questions

Do I still need to force password changes every 90 days?

No, and current NCSC guidance actively advises against it. Routine expiry pushes people towards predictable increments, which weakens rather than strengthens your position. Change credentials immediately when there is any suspicion of compromise. Write the rationale into your policy so the decision is visible and documented, and it will not cause you a problem in an audit.

Is SMS-based MFA good enough for ISO 27001?

It is acceptable and it is very much better than nothing, but it is the weakest of the common factors because of SIM swap and interception. Use an authenticator app as your baseline where you can, and phishing-resistant methods such as passkeys or hardware keys for administrative accounts. What you should not do is leave an account with no second factor while you deliberate over the best one.

Are password managers allowed under ISO 27001?

Yes, and they are the practical answer to unique credentials across dozens of services. Use a business tier rather than personal accounts so that you keep administrative recovery and can remove access when somebody leaves, and protect the manager itself with multi-factor authentication.

What do I do about a system that cannot support MFA?

Record it, do not hide it. Note why the factor is unavailable, apply whatever compensating controls the system permits such as IP restriction and a long unique password, limit who holds an account on it, raise it with the supplier, and set a review date. A documented gap under active management is a reasonable position. An undocumented one is a finding.

Does MFA belong to control 5.17 or control 8.5?

Both, in different senses, which is why people find it confusing. The requirement to use MFA belongs in your access control policy under 5.15. Handling of the authentication factors themselves sits under 5.17. The technical enforcement at sign-in is 8.5. In practice auditors assess the whole picture rather than policing the boundary, but knowing the split helps you file your evidence in the right place.

How should a new starter receive their first password?

Ideally they should not receive one at all. Both Microsoft 365 and Google Workspace can issue a time-limited activation link that lets the user set their own credential, which means nobody ever transmits a secret. If you must set an initial password, send it by a different channel from the username, force a change on first use, and never reuse a house format across starters.