What should organisations do when administrators are not required to use two-factor authentication?

Organisations should require two-factor authentication for all administrators, especially in multi-tenant environments where a single weak account can affect more than one tenant boundary. Admin MFA reduces the risk of credential abuse and makes privileged access harder to misuse. The control should be enforced centrally, not left to individual administrator preference or opt-out behavior.

Why This Matters for Privileged Access Governance

When administrators are not required to use two-factor authentication, the organisation is effectively treating privileged access as if a password alone is enough to prove intent. That is a weak assumption for any admin account and becomes much more dangerous in environments where one credential can alter security settings, reset identities, or affect multiple tenants. MFA does not eliminate compromise, but it sharply raises the cost of routine password theft, phishing, and reuse.

This matters most where administrative access is shared, delegated, or remotely reachable, because the impact of one account being abused is rarely limited to a single task. Stronger authentication is not just a login preference; it is a control that helps preserve accountability around high-impact actions. In practice, many organisations only discover the gap after a privileged account has already been used in a way that should never have been possible.

How It Works in Practice

The practical answer is to make two-factor authentication mandatory for every administrator, with no opt-out path for convenience or legacy exception handling. The control should be enforced centrally through identity policy, because optional MFA tends to fail under pressure: emergency access, onboarding shortcuts, contractor exceptions, and old administrative roles that were never revisited. If an admin account can bypass MFA, then the organisation has not standardised privileged authentication, it has merely recommended it.

For most teams, the right implementation pattern is to pair MFA with privileged role separation, short-lived elevation, and clear recovery procedures. That means distinguishing everyday user access from administrative access, and making sure the stronger factor is required before any change that can affect tenant boundaries, security policies, or sensitive configuration. Current guidance suggests that the strongest value comes when MFA is applied to the accounts that can change access itself, not only to the dashboards people log into most often.

Require MFA for all administrator roles, including break-glass accounts with tightly controlled exceptions.
Enforce the policy at the identity provider or central access layer, not inside individual applications.
Review whether service desks, contractors, and delegated admins have the same requirement.
Log and alert on privileged access attempts that do not complete MFA successfully.

NHI Management Group notes that 97% of NHIs carry excessive privileges, which is a useful reminder that over-privileged accounts and weak authentication often appear together rather than separately. In tenant-heavy environments, admin MFA should be treated as a baseline control for preventing one compromised login from becoming a control-plane event. These controls tend to break down when legacy admin accounts are exempted or when emergency-access procedures are left untested, because attackers and users both learn to route around the strict path.

Common Variations and Edge Cases

Tighter authentication often increases operational friction, so organisations have to balance resilience against support burden and recovery speed. That tradeoff is real, especially for administrators who need access during outages or from constrained environments, but it does not justify making MFA optional. The better approach is to design for exceptions explicitly rather than letting them become the default operating model.

There are a few common edge cases. Shared admin accounts should be eliminated where possible, because MFA loses much of its accountability value when multiple people use the same login. Legacy systems that cannot support strong authentication should be isolated, monitored, and scheduled for replacement rather than used as a standing justification for weaker policy. For highly sensitive estates, step-up authentication for especially risky actions can complement baseline MFA, but it should not replace it.

Where organisations operate across multiple tenants or customer boundaries, the control needs to be evaluated against blast radius, not just login success rate. The question is not whether administrators can still work quickly; it is whether a single stolen credential can reach too far, too silently, or too broadly. For that reason, the safest default is to require MFA everywhere an administrator can make a materially impactful change.

Risk and Threat Considerations

The material risk is privileged account takeover leading to unauthorised configuration changes, tenant crossover, or wider administrative abuse. When MFA is optional, password theft, phishing, and credential reuse become enough to reach high-impact functions that should have a stronger trust check.

Failure mechanism: An attacker obtains or reuses an administrator password, then uses the missing second factor to authenticate directly, bypassing a control that was supposed to distinguish a valid admin from a stolen credential.

Impact: The result can be tenant compromise, account lockout, security-policy tampering, data exposure, or persistence through changes that weaken later detection and recovery.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Mandatory admin MFA is core access control for privileged accounts.
Recommendation — Enforce MFA for all privileged accounts and remove standing exceptions.
NIST CSF 2.0	PR.AC-1 — Identities and Credentials Managed	Admin MFA strengthens identity proofing and credential use for privileged access.
	PR.AC-4 — Access Permissions and Authorizations Managed	Admin MFA supports controlled authorization for high-impact actions.
Recommendation — Require strong authentication for privileged identities before granting access. Tie privileged actions to authenticated, policy-enforced access paths.
NIST Zero Trust (SP 800-207)	SC-4 — Identity Assurance and Continuous Verification	Zero trust requires stronger verification for privileged administrative sessions.
Recommendation — Verify administrative identity before allowing access to sensitive control paths.
NIST SP 800-63	AAL2 — Authenticator Assurance Level 2	Admin access needs stronger authenticator assurance than password-only login.
Recommendation — Use at least AAL2 authenticators for administrative authentication.

Practitioner Guidance

What to prioritise: Treat any administrator role without mandatory MFA as a high-risk exception and remove the exception before expanding the role further. The first accounts to fix are the ones that can change authentication policy, reset other admins, or administer multiple tenants.

What to verify: Confirm that MFA is enforced at the central identity layer for every privileged path, including API-based admin access, break-glass usage, and delegated support roles. If one path is exempt, the control is not complete.

Decision rule: If an admin account can affect security settings, tenant boundaries, or identity recovery, MFA should be non-optional; if it cannot be enforced, the environment should be treated as materially weaker until it can.

Practitioner takeaway: Optional MFA for administrators is not a soft control choice, it is a privilege boundary decision that directly changes how much damage a stolen password can do.