For Annex A control 8.5, "Secure authentication", the strongest evidence is a configuration export showing multi factor authentication or single sign on is enforced, paired with a user level report showing coverage and a record of exceptions. A policy statement alone shows intent, not operation.
Enforced versus available
Many tools offer multi factor authentication as an option. Evidence needs to show it is enforced, meaning an account cannot sign in without it. Control 8.5 is titled "Secure authentication" in the 2022 edition of Annex A, and the standard text decides what you must meet. Start by deciding which systems are in scope: identity provider, source host, CI, cloud consoles, registries, ticketing and the admin tools for your product.
For each system, capture three things: the policy setting, the user level state, and the exceptions.
What to capture per system
| System | Setting to export | User level view |
|---|---|---|
| Identity provider | Sign in policy requiring a second factor | Report of users enrolled |
| Source host | Organization setting requiring two factor | Members without it, expected to be empty |
| Cloud console | Account policy and root account protection | Users with and without a second factor |
| CI and registry | Single sign on enforcement or token policy | Service accounts listed apart |
Take the export with the date visible, and do it again at each review. If a vendor shows the setting only in a web page, a dated screenshot of the setting page together with the user report is acceptable proof of state for many assessors, but check with yours.
Steps to get to a clean report
- Make the identity provider the front door for as many tools as possible.
- Turn on enforcement, not just encouragement, and set a grace period with an end date.
- Run the user level report, and chase each account without a second factor.
- Separate service accounts and give them owners and token expiry instead of passwords.
- Prefer phishing resistant methods for admins where your tools support them.
- Record exceptions with a reason, a compensating control and an end date.
- Re run the report monthly and keep the output.
Pitfalls
Local accounts that bypass single sign on. Break glass accounts without a documented control. Legacy tools that cannot enforce a second factor and are not listed as exceptions. Shared mailboxes used as login identities. Evidence taken once at audit time, which shows nothing about the other eleven months.
A quick test: pick three random people and ask whether each could sign in to the source host with only a password. If you cannot answer in a minute, your evidence is not ready.
Where Safeguard fits
Safeguard includes agent identity and an MCP Guardrail, along with compliance and evidence automation, if you need access and tool call records for AI agents. You can try the free scan at gold.safeguard.sh/scan. An auditor decides what counts as sufficient evidence.
Quick check
Is single sign on the same as multi factor authentication?
No. Single sign on centralizes sign in. Whether a second factor applies depends on the policy in the identity provider, so show that policy.
Do customers see this evidence?
Often they ask for a short summary. Share the statement and offer the detailed export under your normal confidentiality terms.
Sources
- ISO 27001 Annex A controls list, Security Compliance Guide
- ISO 27001 Annex A controls explained, Glocert International
Last reviewed: 19 October 2026.
