The setup of Multi-Factor or Two-Factor Authentication (MFA/2FA) for schools, need not be majorly impacting and can be straightforward, for all accounts.
Multi-factor or Second-Factor authentication is a requirement 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/2FA 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/2FA?
Simply put, the key here is "Multiple" Factors of Authentication, and of course, we all understand that being a mobile device with an app or receiving an SMS are not the only solutions 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 coming. This is a second factor in authentication and, when used, can prevent a traditional MFA/2FA prompt, allowing the user to work seamlessly with just a username and password.
Sometimes, a device itself, joined for example to Microsoft Entra ID (previously Azure Active Directory) is something you can use, just as you would a trusted IP address, as mentioned above. You may also use device certificates (if you have an internal certificate authority) to ensure you know the device is yours.
After successful authentication, users (if enabled to do so) can mark a device as trusted and ensure that MFA/2FA prompts are not fired when logging in.
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 answer when we are looking at protecting students' accounts. Additional authentication controls are an area of concern to the leadership team and teachers within the school, as they are perceived as a challenge for 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 GSuite one), from someone outside, obtaining their credentials (most commonly through phishing, or peer-on-peer access) and gaining access to their cloud account. 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?
Now, thinking of the above, we can trust the school locations (so no MFA prompting) and, where possible, trust the devices we own (again, no MFA prompting). So, what we are left with is our students when working from home (if they need to use the account).
Our Year 7+, who will most likely already have a mobile phone, can be configured with MFA (a little support at the beginning of their secondary school journey). Of course, this is only for access outside of school.
Our Year 6 probably has a mobile, as this seems to be when they appear, but of course, in primary school, in the last year, it may not be worth considering the use of their device.
Otherwise, we need to have MFA/2FA firing when our students log in from an unknown (unknown is the keyword here - see later) web browser or device, but perhaps for our <Year 7 and any SEND students, we consider four things, delivered together, to reduce impact:
- We will send an email with the MFA code when it's needed to a parent's/carer's email address (which we will already have on file) or the parents' mobile device.
- Allowing the device to be trusted ensures it only asks the first time it's used.
- Setting a long timeout for MFA/2FA repeat requests (365 days, for example).
- Allow persistent browser sessions.
Thus, if we deliver using the four items above, we have protected the account. It 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 also should not be significantly difficult for the parents.
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.
Setup of this solution
ICT can take an export from SIMS, for example, which has the child identifier that can be used to find the child in the cloud directory service, and that, along with the parent's email address (in a CSV file for example) can be uploaded into the system, so all the MFA details are pre-set (Primary School) or, on the first day of term, when the username and password are provided to the student, they can set up their mobile for MFA/2FA (Secondary School etc).
I know that in my son's school, personal devices are used in the classrooms sometimes.
Where Available
If your cloud application offers MFA via any of the options listed below, you must enable and deliver whatever option is most sensible for your environment. This requirement comes 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 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