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 indeed 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, whilst not, on its own, a compliant form of MFA, can be used in conjunction with other methods to ensure that MFA is not required within the school learning environment.

The device itself may also be trusted based on its known Domain/EntraID-joined status and thus does not require MFA, ensuring that students are not impacted by MFA requests when using a known device.

We also have options, such as security keys, code tokens, and other additional factor-providing offerings. Still, generally speaking, the above are most suited to a school and, more specifically, students within the school environment.

What are we protecting?

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

Well, what we are trying to protect against here is the student's cloud account (most likely a Microsoft 365 account or potentially a G Suite one) from someone outside obtaining their credentials (most commonly through phishing or peer-on-peer access) and gaining access to it. But also, 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 for MFA.

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

Given the above, we can trust the school locations (so no MFA prompts) and, where possible, trust the devices we own (again, no MFA prompts). 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). Of course, this is only for access outside of school, especially if your 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 when needed to a parent's/carer's email address (which will already be known) or the parent's mobile device.
Allowing the device to be trusted ensures it only asks once.
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: If we remember, we can trust a device (so don't ask for 2FA/MFA) after it has first been authenticated, and indeed, trust the browser; therefore, we are only going to ask for MFA every 12 months and any time the account is used on a non-school device, where it has not previously been authenticated.

Set up of this solution

In most cases, student accounts are created from entries from within the school management system (e.g. SIMS) and thus, along with 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 individual credentials are provided to students where, on first logon, they can set up their mobile for MFA (Secondary School etc), before the introduction of Yonda-Pouches and no-mobiles within the school environment.

Where Available

If your cloud application supports MFA via any of the options listed below, you must enable and deliver the option that is most sensible for your 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 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