Cyber Essentials Plus MFA Evidence, the Acceptable Formats by Identity Provider

Net Sec Group is an IASME and NCSC certification body. Across our 800-plus engagement history, MFA evidence is the audit-pack section that decides User Access Control more reliably than any other artefact. The assessor reads the MFA evidence to verify multi-factor authentication is enforced on every cloud admin account in scope; the IASME CE Plus test specification and the Cyber Essentials Requirements for Infrastructure (NCSC, v3.x current) set the bar.

This article enumerates the MFA evidence formats the assessor accepts per identity provider, the formats the assessor rejects, the assessor-accepted MFA factor list, and a sample MFA evidence cover page that ties the artefacts together. For the broader screenshot specification covering all five controls, see CE Plus evidence screenshots checklist on this site.

What the assessor needs to verify

Three claims need to hold for the User Access Control MFA test to pass at CE Plus:

Enforcement is on: MFA is configured to require a second factor on every sign-in, not merely available for users to opt in.
Scope covers every in-scope admin account: the enforcement applies to all administrator accounts, including service accounts where applicable, break-glass accounts, and admin accounts on every cloud service in scope.
The factor is one the assessor accepts: the configured factor type meets the NCSC MFA guidance bar for cloud admin.

Each identity provider produces different artefacts that evidence these three claims. The table below names the artefacts per provider and describes what the assessor accepts and rejects.

The 4-row identity-provider-by-evidence-type table

| Identity provider | Primary artefact | Supporting artefacts | What the assessor accepts | Typical reject | |---|---|---|---|---| | Microsoft Entra (Microsoft 365 / Azure) | Conditional Access policy export showing the policy named, target users (all administrators role assignments), grant control (require MFA), state (on, not report-only) | Authentication Methods Activity report (Microsoft Learn reference), Sign-in log filtered to admin accounts showing the MFA claim was satisfied for the last 7 days | Conditional Access policy in production tenant, on, scoped to all administrator roles, grant control "require multifactor authentication"; supporting authentication methods report shows admin accounts have MFA registered; supporting sign-in log shows MFA claims satisfied | Security Defaults toggle without admin-scope evidence; Conditional Access policy in report-only state; sign-in log filtered to non-admin tenant only | | Google Workspace | 2-Step Verification enforcement screen (Google Workspace Admin Help reference) showing enforcement on for the admin organisational unit | 2SV enrollment audit log per admin user, admin audit log showing the enforcement-on event | 2SV enforcement on for the admin OU (or all-OUs), supporting audit log showing every admin account is enrolled in 2SV, no exception groups | Enforcement on but with an exception group containing admins; per-user 2SV enrolled flag without enforcement; non-admin OU enforcement only | | Okta | Factor Enrollment Policy showing the admin group requirement, plus Group Rule that puts admins into the required-MFA group | System Log filtered to admin authentication events showing the MFA factor verification, Factor Enrollment report | Factor Enrollment Policy on for admin group, Group Rule auto-assigns admins, System Log shows MFA verification on admin sign-ins | Policy on but admin Group Rule missing or stale; System Log empty for admin role group (admins logging in via separate path); factor enrollment without enforcement policy | | Duo (commonly for non-cloud admin or VPN) | Admin Policy showing required factors and the application/service it gates | Authentication log filtered to the admin role group | Admin Policy with required factor list (security key, authenticator, push with number matching), authentication log shows MFA verification for admin sign-ins | Policy on but with bypass rules for the admin group; authentication log empty (admins skip Duo via fallback); SMS-only configured as the required factor for cloud admin |

The three rejection categories we see

Across our engagement history, three MFA evidence patterns recur on rejection.

Reject 1, a setting toggle that does not prove enforcement on the population

The applicant submits a screenshot of the "MFA enabled" toggle in the identity provider's general settings. The toggle indicates the platform supports MFA, not that any specific population has it enforced. The assessor reads it as scope-undefined and rejects. Fix: capture the policy or rule that scopes the enforcement to the admin population, plus the report or log evidence that admins have actually authenticated with MFA in the recent past.

Reject 2, a report missing the admin tier

The applicant submits a User Access Control report from the identity provider that shows MFA enrollment for the user population. The assessor filters for admin accounts and finds them missing or shown as not-enrolled. The applicant's defence is "those admins use a separate sign-in path" or "the report excludes service accounts by default". The assessor reads the gap as a control gap. Fix: regenerate the report including admin and service accounts, with explicit handling (separate sub-report or footer note) for accounts the firm believes are out of scope.

Reject 3, attestation without supporting export

The applicant submits a written statement that "all admin accounts have MFA enforced" without the policy export or log evidence. The assessor reads it as undocumented attestation. Fix: produce the policy export and at least one log or report extract showing the enforcement is active.

The assessor-accepted MFA factor list

The IASME assessor follows NCSC guidance on factor strength. For cloud admin accounts, the accepted factors are:

Hardware security key (FIDO2, U2F): top-tier accepted, documented as the strongest factor for cloud admin
Authenticator app push with number matching (Microsoft Authenticator, Google Authenticator, Authy with verified configuration): accepted
Authenticator app TOTP (time-based one-time password): accepted
Authenticator app push without number matching: accepted but the NCSC MFA guidance recommends number matching to mitigate push-fatigue attacks

For non-admin accounts, the bar relaxes:

All factors above are accepted
SMS-based one-time codes: accepted for non-admin only; NCSC discourages this for sensitive roles but does not prohibit it
Email-based magic links: accepted for non-admin only and only with a compensating control (the email account itself protected by stronger MFA, conditional access blocking suspicious sign-ins)

For cloud admin specifically, SMS-based MFA gets queried by the assessor. The recommended path is to upgrade admin accounts to authenticator-app or hardware-key MFA before the engagement.

A sample MFA evidence cover page

The assessor reads a single-page summary alongside the policy and log artefacts. The cover page binds them together and gives the assessor an at-a-glance verification. The structure below is the field set we have seen accepted across the engagement history.

Cover Page: MFA Evidence for CE Plus

Control: User Access Control, MFA on cloud admin
Identity provider: <e.g. Microsoft Entra (Microsoft 365 tenant: contoso.onmicrosoft.com)>
Enforcement scope: <e.g. all directory roles assigned to administrative principals>
Factor list (accepted by NCSC for cloud admin):
  - Microsoft Authenticator with number matching (primary)
  - FIDO2 hardware key (backup)
Evidence as-of date: <ISO date>

Artefacts (in this evidence pack):
  1. Conditional Access policy export (PDF, file ref: CA-Policy-Admins-MFA.pdf)
  2. Authentication Methods Activity report (PDF, file ref: Auth-Methods-2026-05-07.pdf)
  3. Sign-in log filtered to administrators, last 7 days (CSV, file ref: SignIn-Admins-7d.csv)

Control owner: <named human, role>
Sign-off date: <ISO date>

The cover page satisfies the assessor's first read. The supporting artefacts answer follow-up questions if any. The bulk of engagements pass User Access Control cleanly on this evidence structure.

Practitioner observations

Three observations from the engagement history.

1. Conditional Access on Microsoft Entra is the cleanest path for cloud admin MFA evidence, because the policy export, the authentication-methods report, and the sign-in log all live in one console and reference each other. Engagements on tenants without Entra ID P1 (free-tier-only Microsoft 365) have to compose evidence from Security Defaults plus per-user MFA reports plus sign-in audit logs, which produces a thicker evidence pack for the same control.

2. Service accounts surface late. The admin-account list reconciles cleanly until the assessor asks "what about the service account that the backup tool uses". Service accounts with administrative privilege need either MFA via a service-friendly mechanism (hardware key in a sealed enclosure, certificate-based authentication that satisfies the MFA control), or replacement with a managed identity (Azure managed identity, AWS IAM role, GCP workload identity federation) that does not authenticate interactively. See the User Access Control and understanding passwords articles on this site for the foundation references; for the broader cloud-only treatment, the .io sister site has the cloud-only business scope playbook.

3. Break-glass accounts need MFA too. A break-glass admin account that bypasses Conditional Access for emergency-access purposes is in scope and must have MFA enforced through the bypass mechanism (a hardware key locked in a sealed envelope is the assessor-accepted pattern). An account that bypasses Conditional Access without MFA fails the control regardless of how rarely it is used.

Common questions

Does the assessor accept Security Defaults on Microsoft 365 instead of Conditional Access?

Yes when the tenant is on a Microsoft 365 plan that does not include Entra ID P1 (Conditional Access requires P1). Security Defaults enforces MFA on administrators automatically; the evidence is the Security Defaults toggle plus the per-admin authentication-methods report. Tenants on Entra ID P1 or higher should use Conditional Access for the cleaner audit trail.

What about per-user MFA in the legacy Microsoft 365 admin centre?

Per-user MFA is being retired by Microsoft. It still works for now but the assessor accepts it grudgingly with a footer note. New deployments should use Security Defaults or Conditional Access. See the legacy per-user MFA portal at the Microsoft 365 admin centre while it remains available, but plan migration.

Can I use a third-party MFA provider in front of Microsoft 365?

Yes when the third party (Okta, Duo, Ping) is configured as the identity provider for Microsoft 365 sign-in, and the third-party policy enforces MFA on every admin sign-in path. The evidence is the third-party policy export plus the federation configuration showing Microsoft 365 trusts the third party for authentication.

What MFA does the assessor accept for password manager admin accounts?

The same factor list as for any cloud admin: hardware key, authenticator app, TOTP. SMS gets queried for password manager admin because the password manager typically holds high-value credentials. Move admin accounts to authenticator-app or hardware-key MFA before the engagement.

Where do we book CE Plus?

Book a Cyber Essentials Plus assessment with Net Sec Group. The booking form lets you describe the identity-provider topology; the assessor confirms the engagement timeline.

Reference material

Where this fits on this site

This article is the MFA-evidence spoke under the audit-evidence pillar of this site. The other audit-evidence spoke is CE Plus evidence screenshots checklist. For the platform-specific configuration detail referenced in the per-identity-provider sections, see the upcoming Intune for CE Plus configuration and Google Workspace for CE Plus under the platform-specific hub. For per-control foundation references, see User Access Control, understanding passwords, and password attacks explained on this site.