Why SEND software should require two-factor authentication

A school can lose confidence in its software long before a regulator publishes an enforcement notice.

We saw that first-hand in conversations with data protection officers. Some were so frustrated with a large, established incumbent education-data provider that they were considering cancelling their contracts and reporting their concerns to the Information Commissioner's Office (ICO). We are not naming the provider, and we are not presenting those conversations as a verified enforcement case. The point is what the conversations showed us: trust can disappear when a supplier is slow to answer sensible questions about sensitive information.

A support ticket that takes weeks is annoying when it concerns a cosmetic feature. It is a governance problem when the question is who can access children's special educational needs and disabilities (SEND) records, where information flows, or what happens after a suspected breach.

That experience shaped MeritDocs. We did not want to build another large, slow-moving system and attach a security page afterwards. We wanted data protection, access control and accountability to affect the product from the beginning.

The short answer

School-wide two-factor authentication should be a baseline for software that handles children's and SEND information. A password can be stolen through phishing, guessed, reused across services or tested in a credential-stuffing attack. A second factor means a stolen password is no longer enough on its own.

The UK General Data Protection Regulation (UK GDPR) does not say that every software platform must use two-factor authentication. It requires security measures appropriate to the risk. The ICO recommends implementing two-factor or multifactor authentication wherever possible, with greater importance where sensitive personal data could cause significant harm if compromised.[2]

The National Cyber Security Centre (NCSC) also recommends considering multifactor authentication for all user accounts, using stronger controls for privileged accounts, reviewing unnecessary permissions, and logging authentication and authorisation events.[1]

That is why our view is simple: protecting only the administrator account is not enough. A teacher's account can still expose sensitive pupil information.

When raising a support ticket is not good enough for a DPO

The DPOs we spoke with were not asking for fashionable technology. They wanted clear answers and a supplier that treated their questions with the seriousness they deserved.

The frustration was often cumulative:

access arrangements were difficult to explain;
the data flow was not clear enough for a proper review;
support responses took too long;
audit evidence was difficult to obtain;
legacy workflows made basic changes feel unusually hard;
the supplier's answers did not create confidence that risks were being managed.

We cannot verify the underlying programming languages or architecture of the unnamed provider, so we will not claim that a particular codebase caused these problems. Large education systems can accumulate years of complexity, and scale alone does not prove that a provider is unsafe. But the buyer experiences the result: software that is slow to change, slow to explain and slow to support.

For a DPO, that can turn a procurement decision into a risk decision. If a supplier cannot answer clearly before a contract is signed, it is reasonable to ask how quickly it will respond during an incident.

The ICO's recent audit of 28 edtech providers makes the wider lesson clear without naming individual products. The ICO found gaps in areas including data-flow mapping, contracts, data minimisation, retention and Data Protection Impact Assessments (DPIAs), and made 596 recommendations.[6] The report is not evidence that every provider is failing, and it does not establish a universal rate of two-factor adoption. It does show why schools should ask for evidence rather than accept a general statement that a platform is secure.

These supplier questions sit alongside the security controls themselves. See our AI SEND software buyer due-diligence guide for a broader checklist covering data flows, access, contracts and exit.

Why a password is not enough

A password is a shared secret. Once somebody else has it, the service has no reliable way to know that the person signing in is the legitimate user.

Passwords are reused. They are entered into convincing phishing pages. They are exposed in unrelated breaches and tested against other services. The ICO describes this reuse-based attack as credential stuffing and warns that it can lead to account takeovers.[2]

Two-factor authentication adds a second check, usually something the user has. In MeritDocs, that is a time-based code from an authenticator app. The practical result is not perfect security, but a much higher barrier to an attacker who has obtained a password.

The ICO's reprimand of Finham Park Multi Academy Trust is a useful reminder of the consequences of compromised credentials in education. The ICO said an unauthorised third party used compromised credentials to access and encrypt the trust's systems. It recorded that 1,843 UK data subjects were affected and that the trust did not have adequate account lockout or password policies.[3]

That was a school-trust incident, not an edtech-provider case. It does not prove that two-factor authentication would have prevented every part of it. It does show why account security, access controls and incident preparation belong in the same conversation.

What school-wide enforcement looks like

The current MeritDocs account model has a clear boundary between ordinary users, organisation administrators and higher-level super-admin access.

Every administrator account is required to use two-factor authentication. For an enterprise organisation, an organisation administrator can enable the setting called Require 2FA for all organisation users. When that policy is enabled, every enterprise user in that organisation must set up two-factor authentication before continuing. That includes teachers and other ordinary users.

We are explicit about the distinction because procurement copy should describe the product that exists, not the product a supplier hopes to finish later. The school-wide setting is the control we recommend for organisations handling SEND information. It is stronger than protecting administrators alone.

The setting also gives the school a practical governance decision. The information technology (IT) lead, DPO or nominated organisation administrator can decide whether the policy applies to everyone, then review which accounts are present and whether former staff should be removed. The Department for Education (DfE)'s cyber-security standard expects schools to assess staff access and permissions with the DPO and to keep appropriate logging and response arrangements in view.[5]

Who can see your school’s SEND records?

Two-factor authentication answers one question: is this person likely to be the person who owns the account?

It does not answer a second question: what should that person be allowed to see?

That is where role-based access and least privilege matter. People should have enough access to do their job properly, but not automatic access to every record in the organisation.

In a school setting, the practical pattern is usually:

an IT lead, DPO or nominated administrator oversees the organisation account and user access;
ordinary teachers receive the access needed for their work with pupils;
a special educational needs coordinator (SENCO) may need broader access because they coordinate support and reviews, but that access should be granted deliberately and reviewed rather than assumed from a job title;
organisation administrators manage membership and security policy;
higher-level trust oversight should be limited to the small number of people who genuinely need a cross-school view.

MeritDocs' verified account roles are ordinary user, organisation admin and super admin. Schools and MATs should confirm the exact trust structure, account tier and permission boundaries during due diligence rather than assume that a job title maps automatically to a permission set.

The NCSC recommends defining who should have access to which systems, data or functionality, why they need it and under what circumstances. It also recommends reviewing unnecessary privileges and revoking access when it is no longer needed.[1]

Audit trails are part of the answer

If a school suspects that an account has been misused, it needs more than a password reset. It needs to understand what happened.

MeritDocs records security and information-handling activity, including sign-ins, failed attempts, views, edits, approvals and prints. Events include the person, time and address associated with the activity. The organisation's audit log can be provided for review when a school needs to investigate unusual activity, prepare evidence for its DPO or support a breach-response process.

The current public product does not promise that every administrator can open a full audit dashboard and export a comma-separated values (CSV) at will. That would be an inaccurate claim. The responsible promise is that the audit trail exists and that we provide the relevant organisation log when requested.

The NCSC says authentication and authorisation events should be logged and monitored for behaviour that may indicate compromise, such as failed second-factor attempts, unexpected locations, password spraying or lockouts.[1] The DfE also advises schools to discuss the level of logging needed to identify the source of a cyber incident.[5]

Security should be explainable to a DPO

Our DPO conversations changed more than the login screen. They influenced how we think about the whole information path.

We worked with DPO consultants from the beginning of product development. Their advice helped us build a backend data-flow and security architecture map covering how information enters MeritDocs, how it is protected, where processing occurs, how access is controlled, what activity is logged, and how information can be exported or deleted.

That work sits alongside the product controls themselves. MeritDocs processes data in the UK and European Union (EU), uses encryption, keeps artificial intelligence (AI) drafting under zero-retention terms, does not use pupil data to train models, controls access and records activity. Schools still need to complete their own Data Protection Act (DPA), Data Protection Impact Assessment (DPIA) and procurement checks, but a supplier should be able to support that work with clear information.

The ICO's edtech findings specifically identify incomplete data-flow mapping and gaps in DPIAs as common issues. A living map is not a substitute for good security, but a provider that cannot explain its own data flow makes it much harder for a school to assess risk.[6]

Schools and DPOs can request the relevant technical detail, Data Processing Agreement and DPIA notes from MeritDocs at contact@meritdocs.com. Please do not send pupil records, Education, Health and Care Plans (EHCPs) or other sensitive information by ordinary email. A high-level description of the procurement question is enough for us to send the right documentation.

Setting up two-factor authentication in MeritDocs

The setup is deliberately short:

Open the two-factor authentication setup page.
Scan the Quick Response (QR) code with an authenticator app such as Google Authenticator, 2FAS or Aegis.
If needed, enter the setup secret manually instead.
Enter the six-digit code shown by the app.
Save the backup codes somewhere secure.

The app then asks for a current six-digit code at sign-in. Backup codes are available if a user loses access to the authenticator device.

That small setup step is worth the inconvenience. A stolen password alone is no longer a complete route into the account, and the school can apply the same rule to ordinary users rather than treating teachers as a lower-risk category by default.

The decision we recommend to schools

When reviewing SEND software, ask the supplier five direct questions:

Is two-factor authentication mandatory for administrators?
Can it be enforced for every user, including teachers?
Who can change that policy?
Can access be limited by role and organisation?
What audit evidence can the supplier provide after a suspected incident?

Then ask for the data-flow map, DPA, DPIA support, subprocessor information, retention terms and exit process. A polished demo is not enough. A security page is not enough. The supplier should be able to explain what happens to children's information and who can see it.

The MeritDocs security page summarises the controls and the supporting documentation schools can request.

That is the standard MeritDocs applies. The difference is not a claim that every other provider is careless. It is that DPO concerns, school access decisions and data-flow evidence shaped MeritDocs before the product was finished.