A primary teacher who decides on Monday to start typing practice usually hits the same wall by Friday: the software wants an email address for every child, and nine-year-olds do not have email addresses. The workaround most schools invent is worse than the problem. Someone creates 27 fake mailboxes on the school domain, writes 27 passwords on a laminated card, and quietly becomes the administrator of 27 accounts nobody will ever close.
Typing software with no student accounts skips that entirely. Students join a class with a short code and a name the teacher chooses, nothing is verified against an inbox, and no credential exists to be lost, reused or leaked. Schools across the EU have started asking for it by name, and the reason is not convenience. It is that account-based tools drag a data protection process behind them that a six-week keyboarding module was never meant to trigger.
What does typing software with no student accounts actually mean?
It means the student is identified only inside their own class, by a code and a username, with no email address, no password and no profile that exists outside the school. The teacher creates the class, hands out the code, and each student picks or is given a name. That is the whole sign-up.
The distinction that matters is not "no login screen". Plenty of tools still call themselves account-free while creating a permanent user record keyed to a school-issued Google or Microsoft identity. A genuinely account-free setup has three properties:
- No email address is collected, from the student or about the student.
- No password exists, so there is nothing to reset, reuse or phish.
- The identifier is local to the class, so "Maria B" in class 5A means nothing anywhere else in the system.
In Typiq, a desktop typing tutor for Mac, Windows and Linux, that is the class code flow: a teacher creates a class, the app is given the code and a first name, and the practice results attach to that name inside that class. Students who are not part of a school class do not enter anything at all, because the desktop app runs offline with no account of any kind.
Why are schools asking for it now?
Because the compliance cost of student accounts became visible. Between 2021 and 2025 a series of European data protection reviews, most publicly the Danish and Dutch assessments of Google Workspace for Education, put school leaders in the position of having to justify every third-party tool that processes children's data. A typing tutor used for twenty minutes a week now sits in the same register as the learning management system.
Three practical pressures show up again and again in school procurement:
- The DPO question. Every new tool needs a record of processing, a lawful basis, and often a data protection impact assessment. A tool that stores no personal identifiers beyond a first name is a two-line entry instead of a two-week project.
- The IT question. Accounts have to be provisioned in September and deprovisioned in July. Nobody deprovisions in July. Dormant student accounts are one of the most common findings in school security audits.
- The parent question. "What did you sign my child up for?" is far easier to answer when the honest reply is "a class code, and their first name".
None of this is unique to typing. It is just that typing practice has an unusually poor ratio of data collected to educational value at stake, which makes the account requirement hard to defend.
What does GDPR actually require here?
GDPR does not ban student accounts. It requires that you collect only what you need for the purpose (Article 5(1)(c), data minimisation), that you have a lawful basis, that you can delete the data on request (Article 17), and that any vendor processing data on the school's behalf does so under a written processor agreement (Article 28).
Four points that decide most school evaluations:
- Data minimisation is the whole argument. If a typing tutor can teach the home row without an email address, then collecting the email address is difficult to justify under Article 5(1)(c). The test is necessity, not convenience.
- Consent is usually the wrong basis for a school. A public school acting as a controller normally relies on public task or legitimate interest, not consent, because consent given to an authority is rarely freely given. That matters, because a tool designed around "the parent clicks accept" pushes the school toward a basis it cannot properly use.
- The age of digital consent varies by country. Article 8 lets each member state set it between 13 and 16. It is 13 in Sweden, Portugal and Denmark, 16 in Germany, the Netherlands, Poland and Romania. A tool that creates accounts for eight-year-olds inherits that entire question. A class code does not create an account, so it does not.
- Erasure has to be operationally real. "Delete on request" means someone can actually do it in a week, for one student, without a support ticket that goes unanswered. Fewer stored fields means a shorter erasure path.
The honest framing: no vendor can make a school GDPR compliant, and any vendor claiming to is overselling. What a no-account tool does is reduce how much of the school's own compliance work the tool creates.
How does a class code work in practice?
The teacher gets a code when the class is created, writes it on the board, and the students type it once. Practice results then attach to a name inside that class. There is no verification step, no confirmation email and no password, because there is no account to secure.
The realistic sequence in a lab:
- The teacher creates a class and receives a code in the form
TYP-5A-XXXX. - The code goes on the whiteboard, or on a slip taped to each machine.
- Each student opens the app and enters the code plus a first name or nickname the teacher approved.
- Lessons run locally, so a wifi drop mid-lesson costs nothing.
- Speed, accuracy, lesson and practice time sync to the class view when the network returns.
- At the end of the module the class can be closed, and with it the only place those names exist.
Here is what changes between the two models, field by field.
| Stored about a student | Account-based typing tool | Class code, no account |
|---|---|---|
| Email address | Usually required | Never collected |
| Password | Yes, plus reset flow | None exists |
| Full legal name | Common | Not required, teacher picks the label |
| Date of birth | Often, for age gating | Not collected |
| Typing results (speed, accuracy, lesson) | Yes | Yes |
| Cross-device progress | Yes | No, and this is the real cost |
| Advertising identifiers | Present on ad-funded free tiers | None |
| Who can delete it | Vendor support, sometimes the parent | The teacher, by removing the class |
That table is the argument in one screen, and it is also the honest one, because it includes the row where the account-based tool wins.
What do you give up without student accounts?
You give up portability and recovery. Without an account there is no password reset, no login from home, and no progress that follows a student from the school lab to their own laptop. That is a genuine loss, not a marketing footnote.
Specifically:
- No home practice under the same identity. A student practising at home starts a separate local history. The class view shows the school sessions.
- No self-service recovery. If a student types their name differently on Tuesday, they get a second entry. Someone has to tidy it.
- Manual moves. A student changing class is a small administrative action, not an automatic transfer.
- No parent-facing portal. The teacher is the route to progress information, which some schools prefer and others do not.
- Weak identity by design. Anyone with the class code can enter any name in that class. For typing practice that is an acceptable risk. For assessment it is not, and typing modules should not be graded from these numbers alone.
I would rather state that plainly than pretend the trade-off does not exist. A class code is the right default for keyboarding practice precisely because the stakes are low: nobody needs cryptographic certainty about who typed the home row on Tuesday. If your use case genuinely needs verified identity per student, an account-based tool is the correct choice and you should budget for the compliance work that comes with it.
What should you ask before buying typing software with no student accounts?
Ask what is stored, where, for how long, who can delete it, and what happens when the contract ends. A vendor who cannot answer those five in writing is not ready for a school.
A checklist that fits on one page for your DPO:
- What personal data is stored, field by field? Ask for the list, not a paragraph of reassurance.
- Where is it hosted? EU hosting removes the international transfer question entirely.
- Is there a written data processing agreement under Article 28? It should be available on request, before purchase.
- How is deletion performed, and by whom? Teacher-initiated deletion is stronger than a support request.
- Does the app work offline? Offline practice means less student data in transit and a lab that survives a bad connection.
- Are there ads, trackers or third-party analytics in the student-facing app? On free tiers this is the usual hidden cost, and it is worth reading the comparison of typing software for schools before assuming free is cheaper.
- What happens at the end of the year? Ask whether classes expire, and what is retained if they do.
If you are still designing the module itself rather than choosing a tool, the sequencing questions are covered in the practical guide to teaching typing in schools and the primary school typing curriculum. Home educators face a related version of the same privacy question, handled in the homeschool typing curriculum guide. Schools running Chromebook labs have an extra constraint worth reading first, in the notes on Chromebook typing practice.
Typiq's school setup uses class codes for exactly the reasons above, hosts data on an EU server, and offers a free six-week pilot for one class so a school can test the flow before any paperwork. The details are on the Typiq for schools page.
Bottom line
Typing software with no student accounts identifies each student by a class code and a name the teacher chooses, which means no email addresses, no passwords and no user records that outlive the module. Under GDPR that is not a compliance certificate, it is a much shorter compliance conversation, because the data minimisation argument (Article 5(1)(c)) makes itself. The real cost is portability: without accounts there is no password recovery and no progress that follows a student home, which is an acceptable trade for keyboarding practice and a poor one for graded assessment.
Frequently asked questions
Is typing software without student accounts GDPR compliant?
No software is compliant on its own, because compliance belongs to the school as data controller. What a no-account tool does is shrink the school's obligations: fewer stored fields, no credentials to secure, a simpler lawful basis argument and a faster erasure path. You still need a processor agreement under Article 28 and a record of processing.
How do students log in without an email address?
They enter a class code given by the teacher plus a first name or nickname. The code identifies the class, the name identifies the student inside that class only. There is no password step, no confirmation email and no verification, because no account is created.
Can two students in the same class use the same name?
They should not, and most systems will treat identical names in one class as the same student. The practical fix is the one teachers already use for name tags: add a surname initial, so "Maria B" and "Maria S" stay separate. It is worth agreeing the naming convention before the first lesson.
What data does a school actually store when a class uses a typing tutor?
In a class code setup, typically a first name or nickname chosen by the teacher, plus typing results: words per minute, accuracy, which lesson was completed and how long the session lasted. No emails, no birthdays, no photos, no advertising identifiers.
Do students lose their progress without an account?
Progress inside the class is kept and visible to the teacher. What is lost is portability. A student practising at home under no class code builds a separate local history on that machine, and the two do not merge. For a school module that runs in the lab, this rarely matters.
Can parents ask for their child's typing data to be deleted?
Yes, and the school must be able to act on it. In a class code setup the deletion path is short, because removing the student from the class removes the only record. Confirm before purchase that the teacher can perform the deletion without going through vendor support.
Is free typing software cheaper for schools than a paid one?
Not always, once you count what the free tier is funded by. Ad-supported tools place advertising identifiers in front of children and usually require student accounts, both of which add work for the data protection officer. The honest comparison is total cost including staff time, not the licence line.
Does offline typing practice remove the data protection question entirely?
Close to it. A desktop tutor used without a class code keeps everything on the machine, so no student data leaves the classroom at all. The question returns the moment a teacher wants class-wide progress, because that is the point where results have to be transmitted and stored somewhere.
