ISO 27001:2022 Annex A 8.5 secure authentication: what auditors test

The enterprise questionnaire asks which of your systems enforce MFA and how you chose them. Your honest answer is a spreadsheet of good intentions, and the deal is waiting.

This guide covers ISO 27001:2022 Annex A 8.5 secure authentication for IT directors, CISOs and security managers at 25–250-person firms heading into a Stage 2 or surveillance audit. It sets out what the control requires, where MFA is mandatory, how to build it, and what auditors sample in the room.

What does ISO 27001 Annex A 8.5 require?

ISO 27001 A.8.5 requires login strength matched to what sits behind the door. Anything critical needs additional factors, the login mechanics must give an attacker nothing, and every attempt, successful or not, is recorded. It puts identity and credential rules into practice, and replaces 2013 control 9.4.2.

The control sets three expectations:

• Proportion. A password is fine for the lunch-order app. Anything critical demands additional factors.
• Mechanics that leak nothing. No hints about which part of a credential was wrong, no unlimited guessing, no secrets in clear text and no sessions that live forever.
• Visibility. Every attempt gets logged, so abuse can be seen.

A.8.5 does not stand alone. It puts into practice the identity lifecycle in A.5.16 and the authentication information rules in A.5.17, it gates the restrictions enforced under A.8.3, and it is strictest on the admin tier governed by A.8.2.

Its 2013 predecessor was 9.4.2, secure log-on procedures. A Statement of Applicability carried over from the 2013 version should map that control across to A.8.5, and widen it from the log-on screen to every way a person or service proves who it is.

A.8.5 is preventive: strong authentication stops the impostor at the front door, before any other control is tested. It protects confidentiality, integrity and availability, because a hijacked account inherits whatever its owner could read, change or take down.

Attackers log in more often than they break in. They use passwords harvested from other sites or phished that morning, and MFA on the right systems defeats most of that at near-zero cost.

When does ISO 27001:2022 Annex A 8.5 secure authentication demand MFA?

MFA is non-negotiable on the identity provider itself, remote access, cloud consoles, the code platform, finance systems and every privileged account. A low-risk internal tool behind single sign-on can reasonably stay single-factor, provided the decision is documented. The control asks for proportion, not blanket MFA, and an undocumented gap on the critical tier is the failure.

The identity provider (IdP) leads that list because every other login hangs from it. If an attacker owns the IdP, single sign-on hands over the estate.

The NCSC corporate MFA guidance says to mandate strong MFA for every user accessing sensitive data, and it favours corporately trusted single sign-on and context-aware authentication where possible. The ICO guidance on passwords in online services points the same way: use two-factor or multi-factor authentication wherever it is possible to do so.

The commercial cost of a gap arrives early. MFA coverage is one of the first questions in enterprise security questionnaires, cyber insurance proposals and Cyber Essentials assessments. A gap does not read as immaturity. It reads as negligence, to underwriters pricing your premium, to prospects deciding whether to trust you with their data, and to the ICO after an incident.

For every system that stays single-factor, record three things:

• What it holds. The data and the privilege level behind the login.
• Why single-factor is proportionate. For example, SSO in front, no sensitive data, no elevated rights.
• Who owns the decision. A named owner and a review date.

A short tiering register like that turns the auditor's question about how you decided the list into a document you hand across the table.

How do you implement ISO 27001 secure authentication across your estate?

Put every application you can behind single sign-on through one identity provider, so authentication policy is set once and enforced everywhere. Then rank factors: phishing-resistant FIDO2 passkeys first, authenticator-app codes next, SMS as a fallback and never for admin accounts. Risk-based step-up challenges handle unfamiliar devices without burdening everyone.

The sequence we would give a 50-person regulated firm:

1. Consolidate on one IdP. Connect every application that supports SAML or OIDC, and list the ones that do not. Those become candidates for the exception register.
2. Mandate MFA on the critical tier. Set it as one IdP policy covering the systems listed above, not as per-app settings that drift.
3. Assign factors by tier. The table below sets the order.
4. Switch on step-up. An unfamiliar device, location or time triggers a challenge, so the daily login stays quiet.
5. Enforce, don't invite. A policy that lets users opt out in the IdP is a preference, not an enforcement.

SMS codes guarding the crown jewels are usually the easy option rather than a decision, particularly when the IdP supports app or hardware factors at no extra cost. Turn that into a rule: the more privilege an account holds, the stronger the factor. Auditors and insurers increasingly expect exactly that split.

The effort is modest. SSO plus MFA on the critical tier is one to two weeks of work in a cloud-first estate, and it belongs in the first month of any programme because in our view it is the highest risk reduction per hour in Annex A. It assumes a working identity lifecycle, so each person has one identity to authenticate.

Should passwords expire every 90 days under Annex A 8.5?

No. The NCSC recommends organisations do not force regular password expiry, because it breeds predictable variations, and this control's intent favours long passphrases, breach-list checks and MFA instead. Set length over complexity rules, hash stored secrets with Argon2 or bcrypt, and rotate on evidence of compromise.

The NCSC password policy guidance explains the mechanism. People facing a forced change make small, predictable edits, so the new password is easy to guess from the old one. Rotation adds friction and invites weaker choices. The ICO's guidance agrees: set expiry only where it is absolutely necessary.

A policy that matches current guidance has five settings:

• Length over complexity. Long passphrases beat forced symbols and capital letters. The ICO suggests a minimum of 10 characters and no maximum.
• Breach-list checks. Reject passwords known to be breached when they are set or changed.
• No routine rotation. Reset on evidence of compromise, such as a phishing report, a breach-list hit or a leaver who knew a shared credential.
• Modern hashing. A salted, password-specific algorithm such as Argon2 or bcrypt for stored secrets in anything you build.
• MFA behind it. A guessed password then fails at the second factor.

Write the NCSC reasoning into the password policy itself. A reviewer who expects 90 days then finds a cited decision instead of an apparent gap, and the IdP configuration matches the document.

How do you harden the login flow and issue first credentials safely?

Harden the login in four moves: failure messages that never reveal whether the username or password was wrong, lockout or exponential delay after repeated failures, credentials masked and encrypted in transit, and idle timeouts on every session. Deliver new joiners' first credentials out-of-band and force a change at first use.

An auditor will ask to see each login setting, so configure them in the IdP and keep the evidence:

• Generic failures. One message for every miss. A screen that distinguishes an unknown user from a wrong password hands attackers a user-enumeration oracle.
• Lockout or delay. Set a threshold for repeated failures, record it, and make sure every lockout writes a log entry you can show.
• Masked, encrypted entry. Mask credentials as they are typed, encrypt them in transit, and show nothing sensitive before sign-in completes. Add an authorised-users-only notice where legal exposure warrants it.
• Time-boxed sessions. Idle timeouts everywhere, with shorter lifetimes and re-authentication for high-risk applications and admin work.

Sessions are also physical. Conference-room screens left logged in get noticed on the walk to the meeting.

First credentials for new joiners

Deliver the identifier through one channel and the secret through another. A username in the welcome email and a one-time passphrase from the line manager is enough, and the IdP then forces a change at first use. The joiner procedure should say so in writing, so the route can be shown for any recent starter.

The classic failures are easy to invert. A first-day password sent by plain email or Slack sits in searchable history for ever, so it never goes in a message thread. Default admin credentials survive on firewalls, printers and SaaS tenants nobody thought of as systems, so sweep them before the auditor checks an appliance or two.

How should you manage service accounts, API keys and break-glass credentials?

Treat accounts that cannot do MFA as managed exceptions: vault the secrets, scope them tightly, rotate them and monitor their use. Record each exception, with its compensating controls, in a register. Executive exemptions follow the same rule: a recorded, justified exception passes; an unconsidered one does not.

Non-human credentials need four habits:

• Vault. Keep secrets in a secrets manager, never in code, wikis or chat.
• Scope. One account, one purpose, least privilege, and a network restriction where the system allows it.
• Rotate. On a schedule you can defend, and whenever someone with access leaves.
• Monitor. Alert on use from an unexpected place or at an unexpected time.

Break-glass accounts get the same treatment with one addition: every use raises an alert and a review. They exist for emergencies, so any other use is a finding you want to catch first.

The register needs five columns:

• The account.
• Its owner.
• Why MFA is not possible.
• The compensating controls.
• A review date.

An auditor accepts that register and its controls. What fails is the admission that nobody had thought about those accounts.

MFA rolled out "except for" is the pattern to avoid: the CEO who found it annoying, the shared service account, the legacy VPN profile.

An MFA exemption for the person with the most access is the first door an attacker tries.

If a director insists, give them a hardware key instead of a waiver. Where an exemption is truly unavoidable, it goes in the register with an approver and compensating controls, and the list stays short, owned and reviewed.

What do auditors sample when testing Annex A 8.5?

Auditors pull the IdP's MFA coverage report and chase unenrolled accounts, observe a live login for the failure message and step-up behaviour, trace how a recent joiner's first credential travelled, check appliances for default credentials, and request the authentication log for a specific date. Missing MFA on remote access or admin consoles grades major.

Two questions usually come with the samples: how you decided which systems enforce MFA, and how you would spot a credential-stuffing attack this week. The tiering register answers the first. The alerting described in the next section answers the second.

Certification bodies typically grade findings like these:

• Major: no MFA on remote access or cloud admin consoles, or credentials handled in clear text as routine practice.
• Minor: a single unenrolled account, a verbose error message on one legacy app, or a missing lockout on a low-risk system.
• Minor aggregating to major: exceptions that are the norm rather than the recorded, justified rarity.

Keep the evidence pack ready so each of those samples has an answer:

• IdP policy exports showing MFA enforcement, allowed factors, lockout thresholds and password rules, with excluded accounts explained.
• Remote-access and VPN configuration proving MFA is mandatory.
• Coverage reporting on enrolled accounts and exceptions.
• The joiner credential procedure.
• Authentication log extracts and the alert rules watching them.
• Login-screen captures and session-timeout configuration for high-risk systems.

The auditor's first stop is the gap between the policy document and the IdP. Compare each written rule with the live setting before the audit does, and fix whichever side is wrong.

A password policy the identity provider was never configured to enforce is a wish, not a control.

How do you automate MFA coverage and evidence for Annex A 8.5?

Treat the identity provider as both enforcement point and evidence source. A scheduled job reads its API for MFA enrolment and policy state and alerts on any account outside the expected population. Configuration baselines catch drift, attack-pattern alerts watch the logs, and policy exports land in the evidence store on schedule.

Authentication is one of the easiest controls in the standard to monitor, because the IdP's APIs expose nearly everything an auditor asks for. Four builds do the work:

• Coverage as a live metric. The job diffs enrolment against the expected population, so the audit answer to who is not enrolled is a query rather than an investigation.
• Drift detection. Factor requirements, lockout thresholds and session lifetimes are held as code or configuration baselines. Any change outside the change process raises a ticket with the diff attached.
• Attack-pattern alerting. Failure bursts, spray patterns across many accounts and impossible-travel logins feed alerts with a documented response route.
• Evidence on tap. Policy exports, coverage reports and sampled log extracts are generated on schedule into the evidence store.

The third build is the one teams skip. Collecting authentication logs satisfies the logging expectation, but alerting with an owner and a response route turns it into detection.

Authentication logs nobody watches are a record of the breach, not a defence against it.

At this scale the audit pack becomes a by-product of the system running. The same exports answer the next enterprise security review, so a questionnaire about MFA coverage takes minutes rather than a week of screenshots. Designing the identity architecture behind this, including SSO consolidation, conditional access, phishing-resistant factors and service-account patterns, is core to our Cloud Security Architect work. MFA coverage monitoring and drift detection are early builds in our GRC Engineering service.

Frequently asked questions