2FA/MFA in School

The compliant forms of MFA are:

FIDO2 credentials (on trusted platform devices or roaming keys)
Challenge-based authenticator apps
App-based code generators
Message-based methods (email, SMS, and call-based)

ONE OF THE ABOVE MUST BE USED TO BE COMPLIANT

TERMS: (MFA used here to cover MFA, 2FA, and 2SV)

MFA: Multi-Factor Authentication
2FA: 2 (Two) Factor Authentication
2SV: 2 (Two) Stage Verification

MFA is required for cloud applications where it is available (see below for an explanation of "where available") and for all user and admin accounts within that cloud service.

When asked about this, the most common comments from schools are "Really?" and "That is not practical for students," but it is, and it need not be at all impacting (save a little work, setup, and initial prompting).

It is possible to deliver with primary-age children, SEND students and alike, with little overall impact on the child and the learning environment.

Before we get into how, it is important to understand what MFA is. Indeed, it is often misunderstood, with people thinking it is an SMS or app on a phone. While this may be the case, many other "factors" can apply.

The NCSC Article in relation to MFA within education can be found here:

What is MFA?

Simply put, the key here is "Multiple" Factors of Authentication, and, of course, we all understand that a mobile device with an app or an SMS is not the only solution to deliver "multiple factors."

In a school environment, another key factor is a known and trusted IP address (the Internet Address, unique to the school) from which cloud services see all traffic entering the school. This Trusted IP, whilst not, on its own, a compliant form of MFA, can be used in conjunction with other methods to ensure that MFA is not requested within the school learning environment.

The student's device itself may also be trusted based on its known Domain/EntraID-joined status and thus does not request MFA (assuming joining a device to EntraID or another IdP is restricted and requires MFA itself), thus ensuring that students are not impacted by MFA requests when using a known device.

We can also offer other options, such as security keys, code tokens, and other additional factor-providing offerings. Still, the above are most suited to the school's environment.

What are we protecting?

An important question to consider when protecting students' accounts. Additional authentication controls are a concern for the school's leadership team and teachers, as they are perceived as a challenge to delivery, especially when not in school.

Well, what we are trying to protect against here is a student's cloud account (most likely a Microsoft 365 or GSuite account) from being compromised by someone outside the student's group (most commonly through phishing or peer-to-peer access).

However, most likely, the student's accounts are within the same tenant as the actual staff and teachers. We are not worried (generally speaking) about a threat actor managing to steal the device they have, and we trust along with their credentials, hence we can have some levels of device and location trust where MFA is not continually requested, but is still very much set on the account.

So, how do we deliver and make this work in school?

Given the above, we can trust the school locations (so no MFA prompts, again, accounts themselves should have MFA enabled) and, where possible, trust the devices we own (again, no MFA prompts, but in this case, we are talking about EntraID joined devices, and using conditional access to control this). We are therefore left with our students when working from home (if they need to use the account).

Year 7+ will most likely already have a mobile phone, and we can configure MFA (a little support at the beginning of their secondary school journey, requiring mobiles on day 1, but not after, thus Yonda pouches after MFA setup). Of course, this is only for access outside of school, especially if the school is a "no mobile" school with Yonda-Pouches or similar.

Year 6 probably have mobiles, as this is when they appear, but, of course, in primary school, in the last year, it may not be worth considering using their device.

Otherwise, we need to have MFA firing when our students log in from an unknown (unknown is the keyword here - see later) web browser or device, but we can still reduce the overall impact:

We can send an email with the MFA code to a parent's/carer's email address (which will already be known) or to the parent's mobile device.
Allowing the device to be trusted ensures it only asks once and not again for a while.
Setting a long timeout for MFA repeat requests (365 days, for example).
Allow persistent browser sessions.

Thus, if we deliver using the four items above, we have protected the accounts. Our users will only ask once on any new device or browser, will only repeat the check every year, and the parent will be the one (outside of school, remember, not in school) who has the code.

Given that we, as parents/carers, are the ones supervising internet access at home, this should not be particularly difficult for us.

UNKNOWN: Remembering we can trust a device (so not to ask for 2FA/MFA) after it has first authenticated, and indeed, trust the browser; we need only ask for MFA every 12 months and then any time the account authenticates on a new device.

Setting up this solution

In most cases, student accounts are provisioned from entries from within the school management system (e.g. SIMS) and, thus, using other details, such as the parent's email address, can be auto-configured within the system; therefore, all the MFA details can be pre-configured (Primary School) or, on the first day of term, when student credentials are provided for access to their school account, where, on first logon, they can set up their mobile for MFA (Secondary School etc), before the introduction of Yonda-Pouches and a no-mobile policy within the school environment.

Where Available

Where a cloud application supports MFA via any of the options listed below, it must be enabled using a suitable option for your specific environment.

This requirement applies regardless of any associated cost—it is not an option; it is a requirement, and you will not be able to pass a Cyber Essentials Plus (after April 2026, Cyber Essentials Basic as well) assessment if, during the assessment, it is identified that your cloud service supports an option below and has not been enabled.

Utilising Single-Sign-On (SSO) via another provider (e.g. Microsoft, Google)
Utilising another MFA service/provider (e.g. Okta, JumpCloud, and many others available)
Upgrading to a more expensive plan that includes MFA or the ability to use SSO or 3rd party