In a course that took attendance with a QR code and a question, the students in the room passed the question on to those outside. In a class of 1,200, more than a hundred students were identified.
University of Illinois, October 2025Beta
If the student is not in the room, they are not in the attendance record either.
Face verification on the student's own device, physical binding to the classroom, and unannounced repeat rounds during class. Lending a phone, handing over a card or sharing a code does not work. Face verification is not used in high schools — the reason and the cost are written below.
Face data never leaves the phone's secure hardware. Not a single biometric field is ever sent to the server.
Completely free for teachers and students. No app fee, no subscription, no per-student charge.
Problem
Existing systems verify the device, not the person
This is not a theory. Attendance fraud is a documented phenomenon, and it happens at scale.
Students were charged with honour code violations for bringing absent friends' clicker devices to class and answering on their behalf.
Dartmouth College, January 2015Employees printed their colleagues' faces, made $2 masks out of them and fooled a face recognition system that had no liveness detection.
Wenzhou, China, December 2025The IT department of a Turkish university publicly acknowledged in an official notice that its electronic attendance system could be abused, and recommended counting students by hand instead.
Süleyman Demirel University, 2024-25Architecture
Nine layers, nine different questions
No single technology answers all three questions — identity, presence and continuity — at once. So we do not rely on a single technology. One layer collapsing does not invalidate the others — and none of them is sufficient on its own.
Layers 1–6 · “The right person, on the right device, right now?”
1
Account — is this the right student account?
Institutional identity, matching against the class roster, and a consent record. There is no self-registration: accounts are always issued by the institution.
The weakest link — on its own it proves nothing
2
Device — is this the registered physical device?
A hardware-bound, non-exportable key (StrongBox / Secure Enclave) and a device-binding history. The key cannot be extracted from the phone; it cannot be copied.
Closes account sharing and cloned clients
3
App — is this the genuine, unmodified app?
Through Play Integrity and App Attest the app collects the package name, the signing certificate digest and the boot state, and attaches them to the proof.
The limit: the server does not have this token validated by Google and Apple — it stores it and feeds it into the risk signal. What is cryptographically verified on the server is the signature the device produces with its hardware key, and the fields of the key attestation certificate. Detail: Features.
Closes app patching and emulators
4
Identity — is this the right student in front of the phone?
The student performs 1:1 verification on their own phone. The face template stays only in that phone's secure hardware and cannot be extracted from it. There is no classroom scan; no template is created for anyone who has not consented.
Closes phone hand-off, card hand-off and printed photos
5
Fresh physical signal — can it see the current ticket?
The teacher's device acts as an anchor: over Bluetooth and as an animated QR code on screen, it broadcasts an unpredictable ticket that is renewed every 1.5 seconds. The freshness window is five seconds.
A third channel is added: the server sends a one-time challenge directly to the student's registered device, never passing through the anchor. The three channels are combined into a single signature.
Closes attendance from home and the compromise of the teacher's device
6
Human fallback — can the teacher verify physically?
In every round the system picks a few students at random and asks the teacher: Is Ayşe Y. in the room? The teacher looks and confirms.
This is the only layer that closes the relay attack — and it does so probabilistically.
Deters exporting the ticket out of the room
Layers 7–8 · The pattern over time
7
Continuity — did they stay in the room for the whole class?
Attendance is not tied to a single moment. Second and third rounds are run at moments nobody knows in advance. A participation ratio is computed; the institution sets its own threshold.
Closes the check-in-and-leave trick
8
Temporal risk — is the pattern consistent over the term?
Patterns such as the same phone signing on behalf of two students, or two classrooms being covered in an impossible amount of time, do not show up in a single round; they only show up over a term.
This score decides nothing. The strongest thing it can do is ask the teacher to verify the student face to face in that class. The rules are written by hand — no machine learning is used — and no location data is collected.
Catches fraud spread over time that a single round cannot see
Layer 9 · The direction reverses
9
Auditability — if the record disappears, can the student prove it?
After every successful attendance a signed receipt is created on the student's phone. Receipts are chained to one another, and when the class ends a signed digest of all of them is published.
So for the “I checked in but it is not in the system” case, the student can prove that the record was accepted. A record silently deleted from the middle is also detected.
The signature is public-key based, and the keys needed to verify it are published at a public address that asks for no identity. This detail carries the whole layer: if you had to prove your identity to the server before you could obtain the key, verification would depend on the server's permission — that is, the receipt would not be evidence against the server.
This layer protects the student against the system
All six of layers 1–6 can hold and the student can still be at home. None of them answers the question “is the phone inside the classroom?” cryptographically. The relay attack stops exactly here.
Flow
How one round works
The session opens
The teacher picks the course and the classroom. The session is bound to a time, a place and the teacher's device; the policy is frozen at that moment.
The anchor starts broadcasting
Bluetooth, plus an animated QR code on screen. The ticket is renewed every 1.5 seconds.
Notification to the student and a server challenge
The phone detects the anchor and asks for verification. At the same time the server sends a one-time challenge to the registered device, bypassing the anchor entirely.
Face verification
Front camera, liveness detection, matching against the template on the device. The image is erased from memory the moment processing ends.
A single signature
The three channels are combined into one signature by the hardware key. No biometric field of any kind goes to the server.
Receipt
A signed receipt is created on the student's phone: MAK-2026-0314-A7F3. If it does not appear, the appeal route is open.
Spot check
The teacher is asked about a few random names and confirms them visually. Some of them are picked entirely at random.
Unannounced repeat
A second and a third round at moments nobody knows in advance.
Product
Preventing fraud is half the job
Everything above describes how verification works. What an institution actually uses day to day is running a term: a course is opened, a roster is uploaded, a class is cancelled, a make-up class is scheduled, a teacher falls ill, a student asks “how many absences do I have left?”.
Teacher
Live roster while class is running · manual marking with a mandatory reason · past sessions and CSV export · minimum stay threshold · classroom and time changes · offline queue · digitising paper attendance.
Student
Receipts and independent verification · appeals for missing records · class reminders · optional app lock · device eligibility test at setup.
Institution
Start-of-term bulk upload (with a dry run) · usage reports · receipt verification and reconciliation · multi-institution setup · student information system connection.
The cost of each one is written down next to it. What a feature does, what limit it comes with and who has to decide at deployment are all on the features page.
What sets it apart
Six decisions that define the product
These are not a feature list but decisions about how the product works. Each has a cost, and we write that cost down elsewhere on this site.
The person is verified, not the device
The student performs 1:1 face verification on their own phone. A phone that is logged in, a code someone knows or a device within range does not verify a person: when the phone is handed to a friend, none of those layers says anything.
Not one moment but the whole class
Attendance is not tied to a single moment: extra rounds happen at unannounced times during class, and counting as present requires meeting a minimum stay threshold.
Nobody is left outside
A student with no phone, an unsuitable phone, or who does not choose face verification takes part through the teacher-approved route; a reason is mandatory and it goes into the audit log. That is not a workaround outside the system but a path inside it.
The evidence is in the student's hands
For every attendance a signed receipt stays on the student's phone. The signature is public-key: a receipt is verified without asking us, with keys fetched from an endpoint that requires no identity.
An appeal is a workflow
The student turns a missing record into an appeal from the app; the teacher of the course decides it with a written reason, and an accepted appeal really does correct the attendance record. Every step goes into the audit log.
It runs without a network
When the network drops, attendance accumulates on the teacher's device and is sent once the connection returns; the state of the queue is visible on screen. Receipt verification also works offline once the keys have been fetched.
We back none of these decisions with a performance figure. The accuracy of face verification has not been measured and liveness detection has not been measured against any spoofing scenario; that is why there is neither a success rate nor a speed figure on this page. What each piece of work does, and how far it goes: Features.
Privacy
Privacy is not a feature; it is the architecture itself
The template never leaves the device
The face template is created and stored in the phone's secure hardware. There is no central biometric data pool on the server — so there is no pool to breach.
No classroom scan
The camera does not scan the room. No template is created for anyone who has not chosen face verification.
The teacher chooses the method
The teacher decides for each class which routes count as valid; an institution may never enable face verification at all. In institutions registered as high schools, face verification is never used at all — and that is the product's decision, not the institution's: a minor's biometric data requires guardian consent, and we are not building that flow. We do not hide the cost: the remaining methods verify a device, not a person, so a student who lends their phone to a friend will not be caught in those institutions. In a class where face verification is enabled, a student who does not choose that route is marked manually by the teacher. The choice can always be undone with a single tap, and the template is deleted from the phone.
Images are never stored
The frame from the camera is erased from memory the moment verification finishes. It is not written to disk, never sent over the network, never backed up.
No emotion or attention analysis
No inference about emotion, attention or engagement is made from the face, and none will be.
The risk score decides nothing
Outcomes such as failing on absence are never produced automatically. The software component that writes the attendance result has no technical access to the risk records.
Location is never read
The app does not ask for location permission and collects no GPS data. “Impossible travel” detection is derived not from the student's phone but from two attendance records contradicting each other.
The receipt is in the student's hands
For every attendance a signed receipt stays on the student's phone and can be exported. If the system makes a mistake, the student holds independent evidence — appeals stop being your word against theirs.
The student can appeal
The attendance result appears on the student's phone immediately and can be appealed. Of the 18 competing products we examined, none had a structured appeal workflow.
Integration
It works with your school's information system — without asking for your password
We rejected the design that stores the teacher's information-system password and scrapes data through browser automation. In a breach those passwords would turn into plaintext, and most teachers reuse the same password elsewhere.
Open to everyone, the default route. The student roster is imported from a file and the attendance result is written back to a file. The system is fully functional with no integration at all.
The teacher opens their own student information system session inside the app; the device fetches the roster. The server never connects to the SIS, and the password never reaches the server.
Only enabled in allow-listed countries, with written institutional permission and a teacher agreement. There is no automatic discovery: an administrator enters the addresses by hand.
An open specification institutions can implement. Authorisation comes from the institution, can be revoked and can be audited. Moodle mod_attendance and LTI 1.3 also sit at this level.