Multi-factor authentication is the best-value control a school can deploy: a second check beyond the password, which turns a stolen password from a disaster into a dead end. The rollout, though, has three traps — the registration/enforcement gap, the lockout fear, and the accounts nobody planned for. This guide covers all three.
Registered is not enforced — the gap that falsely reassures
Registration means a person has set MFA up (installed the app, linked their phone). Enforcement means the sign-in actually demands it. A school can have high registration and no enforcement — everyone dutifully set it up and nothing ever asks — and every report that counts registrations will smile at you while passwords alone still open every door. When you ask your IT provider “do we have MFA?”, the useful phrasing is: what enforces MFA, for whom, and what are the exceptions?
The two ways Microsoft enforces it
- Security defaults — free on every tenant, one switch: everyone must register, admins must always MFA, users are challenged when needed, and risky legacy sign-in protocols are blocked. No customisation and no exemptions, which is both its strength and its limit.
- Conditional Access — policy-based enforcement (require MFA for everyone, always, with deliberate exceptions and stronger rules for admins). Needs Microsoft Entra ID P1 or above — which, in education terms, means the Microsoft 365 A3/A5 families rather than Office 365 A1. The identity guide covers it properly.
Exceptions, recovery, and the accounts nobody planned for
- Exceptions should be listed, dated and boring. A shared iPad login, a legacy system that cannot cope — maybe. But every exception is a door left ajar, so each one needs a reason, an owner and a review date. An exception list nobody can produce is the finding.
- Recovery is where MFA rollouts die. Phones get lost the first week back. Decide in advance how a locked-out teacher proves who they are (and how the office verifies a caller claiming to be locked out — the attacker rings the office too), or the help desk will quietly become the bypass.
- Break-glass access. Standard practice is an emergency access account excluded from Conditional Access policies, with a very strong credential, locked away and monitored — so a policy mistake or an MFA outage cannot lock the school out of its own tenant. If your provider set your policies up, ask what the break-glass arrangement is; a good answer exists in writing.
- Students are a judgement call by phase — phones in primary schools make app-based MFA impractical, and the risk sits overwhelmingly on staff and admin accounts anyway. Protect the accounts that can move money and data first; extend thoughtfully.
What to keep as evidence
A dated statement of what enforces MFA and for whom; the exception list with reasons and review dates; the recovery procedure; and the break-glass arrangement. That single page answers the DfE’s account-security expectation, most insurer questionnaires, and governor question three in one go. Atlas, with consent, reads Microsoft’s MFA registration report to keep the coverage picture current — and because registration is not enforcement, it presents it as exactly that, never as “protected”.


