MFA is the strategy organisations most often believe they have finished and most often have not. Email is protected, so the box is ticked. Then an assessor asks about the third-party platform holding customer records, or the administrators, or what happens when someone is phished into typing a code.
The requirement grows in two directions as maturity increases: who and what is covered, and how strong the factors must be.
What counts as multi-factor at all
Maturity Level One is specific about the combination. MFA must use either:
- something users have and something users know, or
- something users have that is unlocked by something users know or are.
Two consequences follow immediately. A password plus a security question is not MFA — both are things you know. And a password plus an emailed code is weak at best, because the email account is typically protected by the same password ecosystem.
Scope, level by level
- Level One: users authenticating to your own internet-facing services; third-party internet-facing services holding your sensitive data; and where available, third-party services holding non-sensitive data. Customer-facing authentication is addressed too.
- Level Two: adds privileged users of systems, and requires MFA events to be centrally logged.
- Level Three: adds users and privileged users of data repositories, requires MFA to be phishing-resistant, and requires the logs to be protected from modification and deletion.
The third-party clause is the one that quietly fails assessments. Your own tenancy is easy to enumerate. The list of SaaS platforms holding your data usually is not — and until you have that list, you cannot demonstrate the requirement at all.
Map MFA coverage across every service
GRC Copilot tracks the requirement per maturity level with evidence attached, including the third-party services that make MFA scope hard to prove.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
What phishing-resistant actually means
At Level Three the bar changes qualitatively. Phishing-resistant means the authentication is cryptographically bound to the legitimate site or service, so an attacker relaying the session cannot reuse it.
The practical test: can a user be tricked into handing this to someone else?
- Fails the test: SMS codes, email codes, authenticator app codes, and push approvals. All can be typed or tapped in response to an attacker-controlled prompt. Push fatigue attacks exist precisely because approval carries no binding to the site.
- Passes: hardware security keys and platform authenticators built on origin-bound public-key credentials, and smartcard-style certificate authentication.
This is why Level Three MFA is a programme rather than a setting. It means enrolment, spare keys, loss and replacement processes, and a recovery path that is not itself a phishable bypass — the last of which is where most rollouts leak.
The traps
- Available but not enforced. MFA offered as an option satisfies nobody. Assessors check enforcement policy, not capability.
- Exclusion groups that outlive their reason. The break-glass exemption created during rollout, still populated two years later.
- Legacy authentication protocols left enabled, providing a path that bypasses the policy entirely.
- Service accounts treated as out of scope without documenting why, and without the compensating controls that would justify it.
- Recovery flows that let a caller reset MFA with knowledge-based questions — a phishable path around a phishing-resistant control.
Evidence to hold
Enforcement policy exports rather than screenshots of a settings page; the enumerated list of internet-facing services you operate and third-party services holding your data, each mapped to MFA status and data sensitivity; evidence of the factor types actually in use; from Level Two, central MFA logs; from Level Three, evidence those logs cannot be altered, plus proof the methods in use are origin-bound.
Frequently asked questions
Is an authenticator app enough?
For Maturity Levels One and Two, a time-based code from an app satisfies the factor combination. At Level Three it does not, because the code can be phished — the user can be induced to type it into an attacker's page.
Are push notifications phishing-resistant?
No. Push approval carries no binding to the site being authenticated, which is what makes push-fatigue attacks work. Number matching improves the odds but does not make the method origin-bound.
Does MFA apply to service accounts?
Interactive authentication is the target of the requirement. Service accounts generally authenticate non-interactively and are handled under the privileged access strategy instead, which requires their credentials to be long, unique, unpredictable and managed. Document the treatment rather than leaving it implicit.
What about our customers?
Customer authentication to your internet-facing services is addressed in the model. Where you cannot mandate it, enabling it by default and making it available is the expectation, and the position you take should be recorded.
Key takeaways
- A password plus a security question is not MFA — both are things you know.
- Third-party services holding your data are in scope from Level One, and are the usual gap.
- Phishing-resistant means origin-bound: codes and push approvals do not qualify.
- A knowledge-based MFA recovery flow reopens the hole the control closed.