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 for cloud applications is a requirement within 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.
The most common comments from schools when asked about this 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 very little overall impact on the child and the learning environment.
Before we get into how it is important to understand what MFA/2FA is, and indeed, it is often misunderstood, thinking it is an SMS or app on a phone, when indeed this may be the case, but there are many other "factors" which can apply.
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, however, these are not the only solutions to deliver a "multiple factors".
In a school environment, another key factor is a known and trusted IP address (the Internet Address, unique to the school) which cloud services see all traffic coming from, this is a second factor to 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) thus ensuring you know the device is yours.
After successful authentication, users (if enabled to do so) can mark a device as trusted and ensure, therefore, that MFA/2FA prompts are not fired when logging in.
We also have options, such as security keys, code tokens and many other additional factor-providing offerings, but for now, generally speaking, the above are most suited to a school, and more specifically, students within the school environment.
What are we protecting?
An important question here is to answer when we are looking at protecting students' accounts as this is the "impacting" area of concern to the leadership team and teachers within the school environment, and the perceived 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. 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 we can also, 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).
Perhaps, our Year 7+, who will most likely have, already, a mobile phone, can be configured with MFA (a little support at the beginning of their secondary school journey) and this, of course, is only for when accessing outside of school.
Our Year 6, probably have a mobile, as this seems to be when they appear, but of course, in primary, 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:
- Sending 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 parents' mobile device.
- Allowing the device to then be trusted, ensuring 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 check every year, and the parent will be the one (outside of school remember, not in school) who has the code.
Given as parents/carers we 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).
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. The requirement comes regardless of any associated cost - this 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