What auditors actually ask for
An auditor asking about MFA is really asking for two documents. The first is a coverage matrix, which lists every user type and flags anything without strong authentication. The second is an exception register, which lists every account where MFA can't be enabled, each with a named risk owner and an expiry, plus a compensating control. The two live together because coverage is only complete once the exceptions are accounted for. A 98% MFA rate means nothing if the missing 2% includes your domain registrar and the AWS root account.
The relevant controls are ISO 27001:2022 A.5.17 (authentication information) and A.8.5 (secure authentication), plus NIS2 Article 21 for entities in scope. Control references per ISMS.online.
The few accounts that would end the company on their own get separate treatment in the break glass and root account register.
Why your IdP export isn't the register
Pull the MFA report out of Entra or Okta and it will tell you, with confidence, which federated apps have MFA enforced, because the IdP is the thing enforcing it. What it won't tell you is anything about the accounts that don't authenticate through it. Your domain registrar, your bank portal, the AWS root account, and every vendor console with a shared login all sit outside that export.
Those are precisely the accounts the exception column exists for, and they are usually the most valuable targets in the organisation. An IdP export is a coverage report for the part of your estate you already control. A register is coverage for the part you don't.
The register
Fourteen columns, with three example rows that show accounts at different stages of coverage.
| Account / service | Business owner | Criticality | Behind the IdP? | Auth methods present | Distinct authenticators enrolled | Single point of failure | Recovery codes exist? | Where the codes live | Exception status | Compensating control | Risk owner | Exception expiry | Last verified |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Domain registrar (example.com) | Maria Keller (CTO) | Tier 1 | Direct auth | TOTP + hardware key | 2 | No | Yes | IT vault → registrar folder | 2026-08-01 | ||||
| AWS root account (1111-2222-3333) | Daniel Weiss | Tier 1 | Direct auth | Hardware key | 1 | Yes | Unknown | Not yet enrolled | Second key ordered; break glass held with CEO | Daniel Weiss | 2026-09-30 | 2026-07-20 | |
| Corporate banking portal | Sofia Rossi (CFO) | Tier 2 | Direct auth | Password + SMS | 1 | Yes | No | Accepted | Dual approval above transfer threshold; corporate SIM with swap lock | Sofia Rossi | 2026-12-31 | 2026-07-15 |
Derived columns are shown as-is: Single point of failure reads the count in the previous column and needs no judgement. Cells marked "n/a" mean "not applicable", which is different from "not known". An auditor notices the difference.
Column definitions
1 · Account / service
The account name plus a stable identifier, such as the domain or the AWS account ID. “The Google one” is not an identifier, and neither is “misc”. A bad entry is any name a stranger could not resolve to a specific login. The auditor cares because the register is the index: if an account cannot be uniquely identified, the row cannot be checked against anything, and the whole register loses evidentiary value.
2 · Business owner
A named individual who owns the account’s continuity. “IT team” or “Finance” is not an owner. It is a way of saying nobody owns it. A bad entry is a departed employee, or the same name repeated on forty rows. The auditor cares because accountability only works when there is a human who can answer for an account, and who gets chased when it is offboarded.
3 · Criticality
Tier 1 to 3, where Tier 1 is “losing access stops the business” and Tier 3 is “recoverable with effort”. A bad entry is marking everything Tier 1, which flattens the register and makes nothing urgent. The auditor cares because criticality ordering is what justifies a compensating control. You can only accept residual risk on something once you know how much it matters.
4 · Behind the IdP?
Federated (SSO through your IdP), direct auth (its own username and password), or partial. A bad entry is “probably” or a blank. This column decides whether the IdP export covers the account or the register is its only record. The auditor cares because accounts that are not federated fall outside your identity reporting, and this column is where that gap is made explicit.
5 · Auth methods present
The factors that actually exist on the account: password only, TOTP, hardware key, passkey, SMS. “MFA ✓” is a bad entry because it records a claim, not a method, and SMS and a hardware key are not the same thing. The auditor cares because the control question is not “is MFA on” but “is the authentication strong enough”, and you cannot tell from a checkmark.
6 · Distinct authenticators enrolled
The count of independent factors, not the list. If two people have TOTP apps enrolled on the same account, the number is 2. A bad entry is prose here: a device list written where a number should be. The auditor cares because the count feeds the next column. One enrolled authenticator is a lockout risk, and the register needs to surface that mechanically.
7 · Single point of failure
Derived, not typed: true when the enrolled count is 1. If you fill this in by hand and it disagrees with the count in the previous column, one of them is wrong. The auditor cares because an account with one factor is one lost device away from a lockout, which is the exact scenario the register exists to prevent.
8 · Recovery codes exist?
Yes, No, or Unknown. Unknown is a valid answer, but it has to be dated and resolved. A bad entry is leaving Unknown forever. The auditor cares because recovery codes bypass MFA: not knowing whether they exist, or where, is a finding on its own.
9 · Where the codes live
A pointer to where the recovery codes are stored, such as a vault or a safe, never the codes themselves. A bad entry is pasting actual codes into a shared spreadsheet, which turns the register into the secret it was supposed to document. The auditor cares because a register that contains live secrets cannot be shared with the very people who need to review it.
10 · Exception status
Not possible, not yet enrolled, or accepted, and blank when MFA is in place. A bad entry is an empty cell on a row where everyone knows MFA is not enabled; an unstated exception is a hidden one. The auditor cares because every account with unusual MFA status has to be either fixed or written down, and this column is where you make that choice explicit.
11 · Compensating control
Required whenever exception status is set. A named, testable control that reduces the risk the missing MFA leaves open, such as a second approval step or an IP allowlist. “We’re careful” is a bad entry because it is a sentiment, not a control. The auditor cares because a compensating control has to be provable, not asserted.
12 · Risk owner
The named individual who accepts the residual risk, distinct from the business owner where that distinction matters. A bad entry is “CISO” as a role rather than a person, or one person signing off on every exception in the register. The auditor cares because risk acceptance has to trace to a human decision, not a job title.
13 · Exception expiry
A date. Not possible and not yet enrolled both need one; accepted needs one too. A bad entry is a blank, or a date that has quietly slipped two years into the past. The auditor cares because an exception without an expiry is a permanent policy exemption in disguise.
14 · Last verified
The date a human last confirmed the row is still true. A bad entry is a blank, which means the register is already stale, or a date older than your review cadence. The auditor cares because this column is the freshness proof, and it is usually the first thing they check.
How to populate it
Start from the vendor and spend list, not from the IdP. Finance's invoice list is a better discovery source than any security tool, because every unmanaged SaaS account has a payment method attached. The accounts you forgot exist are still being paid for.
- 01 Export accounts payable and the procurement list. Every recurring charge is an account that needs a row.
- 02 Add what money doesn't show you: the domain registrar, DNS, cloud root accounts, code repos, and social or admin accounts that predate procurement.
- 03 Check the IdP export against the list to fill "Behind the IdP?". Anything federated comes off your manual list; what's left is the register's actual scope.
- 04 For each direct auth account, find the owner and the auth methods, then set the enrolled count and let the next column derive itself.
- 05 For anything not yet MFA'd, set the exception status, the compensating control, the risk owner, and an expiry, in the same sitting.
- 06 Fill "last verified" as you go. The date you confirmed a row is the audit trail for the whole register.
Two rules that make it survive an audit
Registers die from silent staleness, not from wrong data. Two rules keep this one alive:
- 01 Every exception has an expiry. An exception with no date is a policy exemption that never gets revisited, and an auditor will read it that way.
- 02 "Unknown" is a valid entry, but it must be dated. Not knowing is honest; not knowing forever is negligence. A dated Unknown tells the auditor the gap is tracked and scheduled.
Where it breaks
The register answers one question well: what protects this account? It answers the reverse question badly. When a phone is lost or an employee leaves, you'll be asked "which accounts does this authenticator unlock". A spreadsheet can only answer that by scanning every row by hand, under time pressure, while the lockout is happening. That reverse lookup is the thing a dedicated inventory exists for. RecoveryCodes maps accounts to authenticators in both directions, so a lost device surfaces the affected accounts immediately.
Frequently asked questions
Is MFA mandatory for ISO 27001?
Not as an absolute for every account. Control A.8.5 requires secure authentication, and MFA is the default way to meet it, but the standard allows exceptions when they are documented with a risk assessment, a named owner, a compensating control, and a review date. That is the entire purpose of this register.
What is an acceptable compensating control?
Something testable and specific: a second approval step, a hardware key with strong monitoring, an IP allowlist, or extra verification for sensitive actions. “We are careful” is not a control. A control is something you can point to and prove.
How often must the register be reviewed?
There is no universal rule, but quarterly is a common baseline and matches typical audit expectations. The register should carry a “last verified” date per row so staleness is visible, and every exception should be reviewed again at its expiry rather than silently extended.
Do service accounts belong in it?
Yes. Service accounts and API keys are where MFA is usually impossible, which makes them the largest unstated exception. If it authenticates and can cause damage, it belongs in the register with a compensating control.
Download the template
No email gate, no form. The spreadsheet has the same columns plus a second tab with these column definitions.