Ask a district IT director whether staff accounts have MFA and the answer is usually yes. Ask about student accounts and the answer changes. Student MFA tends to stay off, and the reason is rarely that nobody thought of it.
CISA's 2023 report on K-12 cybersecurity puts MFA at the top of its list of near-term investments for schools. It also says plainly that "any MFA is better than no MFA." But the guidance is written about staff, administrators, and people with elevated access. Student accounts are not addressed at all, and the tools on the market follow the same assumption.
Every standard second factor assumes a phone
Look at the second factors Microsoft Entra offers out of the box: an authenticator app, a text message, a phone call, a hardware security key. Each one assumes the person signing in carries a device or a key of their own.
- Authenticator apps and texts need a phone. A second grader does not have one, and many high schoolers are not allowed to use theirs in class.
- Security keys cost money per student, get lost, and have to be handed out and collected on shared carts.
- Phone calls are not workable in a classroom of 25 kids.
Add shared Chromebook carts, where the device in front of a student changes every period, and the options run out. So the setting stays off, and the student side of the tenant runs on passwords alone.
Why student accounts are worth protecting
A student account is not a sandbox. It lives in the same tenant as staff accounts. It can send email, share files, and join Teams. When someone takes over a student account, messages they send come from a trusted internal address, which makes phishing a teacher much easier. From a teacher's account, the path to staff data and admin access gets shorter.
Student accounts also carry their own sensitive material: schoolwork, messages, and the record of what a child said and to whom. Districts have obligations around that data whether or not anyone is attacking it.
The question is not whether students should have MFA. It is what a second factor looks like for someone who does not have a phone.
What a student second factor has to do
From the districts we have worked with, a factor that actually gets turned on for students needs to meet a short list of requirements:
- Work without a phone. Nothing to install, nothing to carry.
- Work on a shared device. The factor belongs to the student, not to the Chromebook.
- Fit the age of the student. A kindergartner can pick a picture. A fifth grader can type a short code. A high schooler can handle six digits.
- Keep resets out of the help desk queue. If every forgotten code becomes an IT ticket, the project will not survive October.
- Bring parents in for the unusual cases. A sign-in at 2 a.m. from another state should go to a guardian, not a technician.
- Store as little student data as possible. The factor needs to verify a sign-in. It does not need grades, IEPs, or demographics.
Where to start
Do not try to turn on student MFA for the whole district at once. Pick one building or one grade band. Scope a Conditional Access policy to that group, run it in a mode that logs without blocking for a few weeks, and watch what happens to sign-ins and support requests. If it works there, expand one grade at a time.
The districts that get this done treat it like any other rollout: small, measured, and with teachers in the loop before the first student sees a new screen.
For the full picture, from choosing a factor to rollout, see our student MFA guide for K-12 IT.
Student MFA without phones
DistrictID adds a second factor for K-12 students behind Microsoft Entra: a passcode or a picture, teacher resets, and guardian approval for unusual sign-ins. Start with a pilot in a sandbox tenant.
See How DistrictID Works