CetusEd
Local-first. There is no central database.
The failure that produced this sector’s largest breach was one vendor holding one database of many districts’ students. CetusEd holds no student database at all — records live on district-managed devices, encrypted before they are written. Nothing about that depends on trusting us to behave: there is no copy for us to hold.
Written for a network administrator · the open items are at the bottom, named
Five parts. Only one holds student data: the device in front of you.
Encrypted before it’s written. Even we cannot recover your keys.
- The data key is generated on the device and is non-extractable — it can encrypt and decrypt, and it cannot be exported, by us or by anyone with the file.
- It is wrapped by the user’s passphrase and by a recovery code your IT department holds, which restores a cleared device.
- Your disk encryption — BitLocker, FileVault — layers underneath as a second, independent control.
- The screen locks after 20 minutes idle by default, and the lock drops the key from memory rather than just hiding the view.
- If the passphrase and the recovery code are both lost with no recent backup, the data is gone — to you and to us. That is the cost of holding no keys, and it is why routine backups are part of the setup rather than an afterthought.
- Any tier that could carry student data off the device is refused in code until the district records a data-processing attestation and configures its own connector address. Until both are true, only de-identified metadata can move.
- If a district enables a cloud tier, it runs on that district’s account. There is no CetusEd-operated service holding student data, and adding one would be a different product.
Out of the box: nothing.
Every outbound request passes through one checkpoint in the software, and it refuses anything the district has not explicitly turned on — including kinds of request it does not recognise. An automated check blocks the release if a new upload path appears that does not go through it.
| Tier | What leaves the device |
|---|---|
| Local (standard) | Nothing. |
| Local plus metadata | De-identified compliance events: staff initials, a hashed student identifier, scrubbed notes. |
| Zero-knowledge cloud | Encrypted backups only. The keys stay with you; the ciphertext would be unreadable to anyone holding it. |
| Custodial | Your own service, on your own account. The only tier that can carry student information, and it carries it to you. |
The app makes no analytics call and loads nothing from a third-party host at runtime. Charting, PDF generation, and all six selectable font families are served from the application’s own origin.
Who can see what , and it’s on the record.
What your security reviewer will find.
Four things have come up in a security review. One remains open — the one no software write can close — and the other three are closed, with the fix that closed them listed alongside, so your reviewer starts from the same list we do.
- CetusEd has not had either. The documentation an assessor would ask for — system description, data inventory and flow map, subprocessor list, control matrix, accessibility self-assessment, and the policy set — is written and available for review.
- Cloudflare, which serves the static files, holds SOC 2 Type II and ISO 27001 for its own infrastructure. That covers the hosting layer and says nothing about this application.
- This was the largest item on the list, and it is closed. Migrating roughly 1,150 inline event handlers and about 900 routed action attributes is complete — every one now routes through the delegation router — and the policy denies inline script and inline event handlers. The build refuses to ship if either count returns.
- The write path is encrypt-first and refuses rather than degrading. The three exceptions this list used to count were each converted into a refusal, the class was re-censused to zero, and an automated check pins the count — a fourth would block the release.
- The one remaining unencrypted store, in-flight examiner state during a testing session, is held in memory only and is never written to disk.
- The scope predicate and its export sibling deny when they cannot determine the unit: an empty school assignment no longer resolves to full visibility, and a scope helper that fails to load is treated as a build defect, not a permission. Both properties are pinned by build-time guards, so a regression to fail-open fails the release.
- A device that has never been configured for a school still opens with an empty workspace — the bootstrap case, by design — and an import or restore bundle the device cannot attribute to itself is refused, with the refusal naming the route that still works.
Aligned to FERPA and Washington’s student-privacy requirements. A dated data-flow and security-hardening packet is available for IT review — ask for it with your pilot inquiry. Worth stating alongside the list: there is no completed pilot yet, so none of this has been exercised under a full district’s daily load.
Read the questions districts actually ask.
Data, encryption, audit, compliance clocks, and what it takes to run this — written for a superintendent, a special-education director, and a network administrator, in that order.
District & IT FAQ Interoperability