Introduction
Multi-Factor Authentication (MFA) has become one of the most widely promoted security controls in modern digital services. Registrars, hosting providers, cloud platforms, and identity providers increasingly present MFA as a non-negotiable requirement, often mandating it as a condition of account access.
From a purely technical perspective, the argument is compelling: MFA reduces the effectiveness of stolen credentials and raises the cost of attack. From a legal, compliance, and operational standpoint, however, the picture is far more complex.
This article does not argue against MFA itself. Instead, it examines the systemic risks introduced by mandatory MFA, particularly when it is implemented without regard for real-world failure modes, recovery obligations, or the legal consequences of denying legitimate access to critical accounts.
For registrars, service providers, and security professionals, the key question is not “Does MFA improve security?” but rather:
“Does this MFA implementation reduce overall risk, or does it merely shift liability while creating new points of catastrophic failure?”
What MFA Is Intended to Do
The primary purpose of MFA is to mitigate credential compromise. If a password is stolen through phishing, malware, or reuse across breached services, MFA should prevent unauthorised access by requiring an additional factor.
In security frameworks, MFA is commonly categorised as a preventive control, not a compensating or detective one. Its effectiveness assumes:
- Independence between authentication factors
- Availability of the second factor
- A functional and accessible recovery mechanism
When these assumptions fail, MFA ceases to be a safeguard and becomes an availability risk.
Mandatory MFA and the Loss of User Agency
From a compliance standpoint, mandatory MFA is often justified using language such as “industry best practice”, “risk reduction”, or “duty of care”. However, mandating a control without accommodating edge cases introduces legal and operational exposure.
The Legal Tension
In regulated or quasi-regulated environments (including registrars), providers owe users:
- Reasonable access to services they have paid for
- Predictable and documented recovery mechanisms
- Proportional security controls
A mandatory MFA policy that results in irreversible account loss due to foreseeable circumstances may be defensible from a policy standpoint, but it is increasingly difficult to defend from a consumer protection or negligence perspective.
Security controls must be proportionate not only to threat, but also to consequence.
Email-Based MFA: A Structural Failure
Email-based MFA remains common despite its well-documented shortcomings. From a security architecture perspective, it is fundamentally flawed.
Why Email Is Not a Second Factor
Email MFA fails the independence test:
- Email accounts are frequently compromised first
- Email is already the primary recovery channel
- Access often relies on the same password hygiene
- Access is often obtained using the same password
In effect, email-based MFA often collapses into single-factor authentication with latency.
Circular Dependency Risks in Registrar Environments
The problem becomes critical in registrar and hosting contexts, where email addresses are commonly hosted on domains managed within the same account.
A real-world example illustrates this failure mode clearly.
In my case, Gandi.net has recently required MFA, of which I was not aware. This morning (3rd February 2026) I had to renew an expired domain. The MFA code was sent exclusively via email to an address hosted on that domain, not the domain, but hosted on the domain. The domain had expired only hours earlier, but email delivery was already disrupted.
The result was a circular dependency:
- Domain renewal required MFA
- MFA delivery required email
- Email required the domain to be active
- Domain was not active and reactivating required renewal
Absent unauthorized workarounds, this design could have resulted in permanent domain(s) loss. This is particularly pertinent as the expired domain resulted in the loss of all contact email addresses that would be required for support communication.
From a compliance and risk standpoint, this represents a design-induced denial of service against the legitimate account holder.
SMS-Based MFA: Exclusion by Design
SMS MFA is often positioned as a universal fallback. It is not.
Practical Limitations
- Not all users own mobile phones (This is me for the last 2 years and life is better!!)
- Some users deliberately avoid mobile devices
- International SMS delivery often is unreliable, particularly when roaming
- Number portability and SIM swap attacks are both documented and common
Requiring a mobile phone as a condition of access imposes a non-neutral lifestyle requirement. In legal terms, this creates an exclusionary control that may not be justifiable where alternative secure mechanisms exist.
iiNet, Internode, TPG etc are guilty of this, I cannot access the account settings of my internet service at all because I don’t have a mobile phone. To pay the bill I have to phone the customer care line and pay manually, they incorrectly cite law and the ACMA as the reason for this requirement.
Compliance Implications
For providers operating internationally, SMS-only MFA may conflict with:
- Accessibility expectations
- Reasonable accommodation standards
- Consumer fairness obligations
e.g. Under Australian Law, This may conflict with accessibility expectations under the Disability Discrimination Act 1992 (Cth) or consumer fairness obligations overseen by the ACCC and ACMA.
Security controls should not assume that all users share the same technological footprint.
Hardware Tokens and App-Based MFA: Strong but Brittle
Authenticator apps and hardware tokens are often presented as best practice. Cryptographically, this is largely correct. Operationally, they still introduce fragility.
Common Failure Scenarios
- Device loss or theft
- Battery depletion
- Device damage
- Factory resets or OS corruption
In isolation, these are manageable risks. The problem arises when recovery mechanisms are inadequate or inaccessible.
A strong MFA factor paired with a weak or opaque recovery process is not a secure system, it is a denial mechanism.
The Recovery Gap: Where MFA Systems Fail
The least discussed aspect of MFA is recovery. Yet from a legal and operational perspective, recovery is the most important component.
Typical Provider Failures
Many providers:
- Require MFA to access recovery options
- Use the same (possibly compromised) email for recovery
- Provide only automated or non-responsive support
- Offer no human escalation path
- Offer human escalation paths that are obscured and often days or weeks in length
Real-World Consequences
Large providers such as Google/Gmail have continually demonstrated that their accounts are not a reliable backup/access point. They often lock accounts due to inactivity and that loss is usually permanent, even for long-standing users, and have no meaningful appeal process. In multiple documented cases, accounts have been terminated or locked with no recovery, including accounts used as identity anchors for other services. For example: I have had 3 Google accounts, one of which was used for purchase of Android applications, all are permanently locked and as such I have lost access to all those purchases.
When MFA is layered onto such systems, users are exposed to compound failure risk: the loss of one account cascades into the loss of many others.
For registrars and infrastructure providers, this is particularly dangerous, as domains frequently underpin identity, authentication, and communication across entire organisations.
When MFA Actively Reduces Security
MFA becomes counterproductive when it causes users to adopt unsafe behaviours:
- Storing backup codes insecurely
- Using shared or third-party email accounts
- Avoiding MFA on critical systems
- Circumventing controls through automation
These outcomes undermine the very risk reduction MFA is supposed to provide.
Security that users must bypass to function is not effective security.
Legal and Compliance Considerations for Providers
From a legal perspective, providers should consider:
Foreseeability
Loss of devices, expired domains, inaccessible email accounts, and provider outages are foreseeable events, not edge cases.
Proportionality
The security control must be proportionate to the harm caused by failure. Locking a user out of a social media account is not equivalent to locking them out of domain ownership. Similarly it also not the same as denying access to legally purchased services such as GPS applications.
Duty of Care
Where providers control access to identity-critical assets, they assume a duty to provide reasonable recovery paths.
Auditability
Recovery processes should be documented, testable, and reviewable, not ad-hoc or opaque.
Lessons for Providers
1. MFA Should Be Optional but Strongly Encouraged
Mandating MFA without flexibility increases legal exposure and user hostility. Encourage adoption through better design, not coercion.
2. Never Use Email as the Sole Second Factor
Email should not be the only MFA or recovery channel, particularly when hosted within the same service.
3. Avoid Circular Dependencies
If access to a resource depends on that same resource functioning, the design is broken. This can be difficult to identify, but it is not the users’ responsibility to ensure this works.
Consider Gandi.net today:
- MFA email to ‘address@example.org‘
- ‘example.org‘ is hosted on a mail server in the domain ‘example.com‘.
- The domain ‘example.com‘ had expired recently (7 hours previously).
- Renewal of ‘example.com‘ required logging into the account with the email ‘address@example.org‘
4. Provide Multiple Independent MFA Options
Users should be able to choose from genuinely independent factors, not cosmetic variations of the same dependency.
5. Treat Recovery as a First-Class System
Recovery is not an afterthought. It is part of the authentication system and should be designed, tested, and audited accordingly.
6. Offer Human Escalation for High-Impact Accounts
For registrars and infrastructure providers, automated recovery is insufficient. Human review must be available, accessible and within reasonable response times where consequences are severe.
Conclusion
Multi-Factor Authentication is an important security control, but it is not inherently safe, fair, or effective. Its value depends entirely on how it is implemented.
Mandatory MFA that relies on email, SMS, or single-device access, without resilient recovery, does not reduce risk. It shifts it, often onto the user, and frequently in ways that are legally and operationally indefensible.
For registrars, Internet Service Providers, Hosting providers, telecommunications providers and security professionals, the challenge is not to enforce MFA at all costs, but to design authentication systems that acknowledge reality:
- devices fail,
- accounts expire,
- providers make mistakes,
- users make mistakes,
- users might not be ideally located when, not if, issues occur (e.g. PTO)
Users should not lose critical assets as a result.