What do organisations get wrong when they roll out MFA for Cyber Essentials compliance?

A common mistake is treating MFA as a checkbox on a single system instead of a control that must be applied consistently. Teams also underestimate user training, weak policy maintenance, and the need to monitor logs for suspicious activity. If MFA is poorly configured or inconsistently enforced, attackers can still exploit gaps in administrative access or externally reachable accounts.

What teams misunderstand about MFA compliance

cyber essentials expects MFA to reduce real access risk, not simply appear on a checklist. Organisations often launch it as a one-time rollout, then leave inconsistent enforcement, stale exceptions, and weak recovery paths untouched. That creates a false sense of coverage: users may be prompted for MFA in some places, while exposed accounts or administrative paths remain reachable elsewhere.

One of the most common failure modes is selective deployment. If MFA is enabled for standard users but not for privileged consoles, remote access, or rarely used accounts, the control misses the places attackers actively target. Consistency matters as much as enrollment, because the practical security value comes from closing the accessible gaps, not from the presence of an MFA policy somewhere in the estate.

Another recurring problem is treating rollout as the end of the project. MFA depends on policy upkeep, logging, exception review, and user understanding. Without those, organisations accumulate bypasses and exceptions that quietly erode the control. The ISO/IEC 27002:2022 Information Security Controls perspective is useful here because access controls are only effective when they are maintained as operating controls, not just configured once.

For compliance-driven teams, the practical question is whether every relevant access path is covered and monitored, including administrative access and externally reachable accounts. If those paths are left out, the organisation may pass a superficial review while still retaining a realistic compromise route. That is why good MFA programmes are assessed by coverage, enforcement, and exceptions, not by whether a product was deployed.

Where MFA rollouts fail in practice

Implementation details usually determine whether MFA becomes a control or a nuisance. Weak enrolment flows, poor recovery procedures, and unclear ownership can all leave accounts in an inconsistent state. If users can self-exempt, if help desk resets are too permissive, or if break-glass access is not tightly governed, the environment can end up with the very gaps MFA was meant to close.

Operational logging is another area teams underestimate. MFA events should be visible enough to support detection of unusual sign-ins, repeated failures, or suspicious bypass activity. When logs are not reviewed, alerting is not tuned, or exception records are not maintained, compromised accounts can persist without being challenged. That is especially relevant where access is exposed externally or used by administrators with broad reach.

Attackers frequently take advantage of the human and procedural edges of MFA rather than trying to defeat the factor itself. Fatigue, social engineering, legacy accounts, and weak recovery processes can all create openings. The Uber Breach is a useful reminder that MFA can be bypassed when user workflow and access governance are weak, while the Microsoft Midnight Blizzard breach shows how a single legacy account without MFA can become a material access path.

Compliance programmes should therefore test the control the way an attacker would encounter it: by looking for unmanaged accounts, forgotten admin paths, and any system where MFA is optional, inconsistently enforced, or overridden by process shortcuts. The point is not just to deploy MFA, but to make it hard to avoid in the places that matter most.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
ISO/IEC 42001:2023	GOV-02 — AI Policy and Accountability	MFA rollout governance needs clear ownership and exception accountability.
Recommendation — Assign ownership, exception approval, and review cadence for MFA enforcement.
NIST CSF 2.0	PR.AC-7 — Users, Devices, and Services Authenticated	MFA is an authentication control that should cover relevant users and services.
Recommendation — Enforce MFA across all in-scope access paths and verify no critical gaps remain.
CIS Controls v8	6.3 — Require MFA for Administrative Access	Administrative accounts are a common weak point when MFA is rolled out incompletely.
	8.2 — Audit Log Management	MFA effectiveness depends on monitoring failures, bypasses, and suspicious sign-ins.
Recommendation — Require MFA for all administrative access paths and remove unsupported exemptions. Retain and review authentication logs for repeated failures, bypasses, and anomaly patterns.
NIST SP 800-63	AAL2 — Authentication Assurance Level 2	Cyber Essentials MFA should meet practical multi-factor assurance for protected access.
Recommendation — Use an assurance level that matches the sensitivity of the protected accounts.

Practitioner Guidance

What to verify: Confirm that MFA is enforced for all externally reachable accounts, privileged access, and any legacy or service-adjacent accounts that can still reach production systems. A rollout is not complete until exceptions are documented, time-bound, and reviewed.

Common mistake: Teams often validate successful login prompts instead of control coverage. That misses the real question: can an attacker still reach a meaningful system through a path that MFA does not cover, or through a recovery process that is easier to abuse than the primary login?

Decision rule: If an account can administer systems, access customer data, or reset other access paths, treat incomplete MFA enforcement as a material exposure, not a minor compliance gap. Prioritise closing those paths before polishing the user experience.

Practitioner takeaway: MFA compliance is only credible when the control is consistently enforced, operationally maintained, and paired with monitoring that can detect the gaps organisations inevitably leave behind.

Framework Alignment

ISO/IEC 27001:2022 Information Security Management: Use Annex A access and authentication controls to ensure MFA is governed as part of the ISMS, not as a one-off rollout.

ISO/IEC 27002:2022 Information Security Controls: Apply the control guidance to maintain MFA enforcement, exception handling, logging, and privileged access coverage.

SOC 2 Trust Services Criteria (AICPA): Map MFA rollout discipline to security and access-control expectations that auditors and customers will test in practice.

CISA cyber threat advisories: Use current threat guidance to prioritise the access paths attackers are actively targeting, including exposed and privileged accounts.

CISA Secure by Design: Treat MFA as a default-secure access expectation that should be hard to bypass and simple to enforce consistently.