Security Practices

Version security@2026-08-08 · In force from 2026-08-08

In force, and prepared in-house.

This document is binding on Firma Limited from the date shown above. It was written by Firma Limited from the source code of the product, and has not yet been reviewed by an independent lawyer — we say that plainly rather than imply a review that has not happened. When that review takes place, no commitment made to schools, families or students will be weakened without the notice process each document describes.

This page describes how Taonova is secured, in enough detail for a school's IT staff or a procurement office to evaluate it. Every claim on it is written from the source code rather than from aspiration, and the gaps are stated as plainly as the strengths — section 10 is the section most vendors leave out. We would rather a school read an accurate list than a reassuring one.

1. The scope of this page

This page covers the Taonova software and the hosted service run by Firma Limited. For a self-hosted installation, everything about the software (sections 3–6) applies, and everything about the environment — hosting, backups, network, encryption at rest — is the school's responsibility: section 11.

This page is a description, not a promise of invulnerability. The promises — what we will do if something goes wrong — are in the Terms of Service (§9), the Privacy Policy (§10) and the DPA (clause 11), and section 8 below summarises them.

2. Encryption in transit

All traffic between a browser and the hosted service is encrypted with HTTPS/TLS. Uploaded files are served through short-lived signed URLs (section 5), so a file address cannot be reused or shared beyond its five-minute life.

Encryption at rest is whatever the hosting platform provides — we do not operate an application-level encryption layer or documented key management, and say so in section 10 rather than implying otherwise.

Passwords a person chooses are stored only as salted bcrypt hashes, via Meteor's standard accounts mechanism, and are never logged.
Accounts created in bulk (CSV import, roster sync, SIS import, invitation) are never given a readable password anywhere: the account is created with a discarded random secret, and the invitation email carries an enrolment link through which the person chooses their own password, using the same server-side token flow as password reset.
Password reset is by a single-use, expiring link sent to the account's email address.
Account creation is rate-limited per client address, and expensive operations carry their own server-side rate limits.
Repeated failed sign-ins are monitored — both many failures against one account and failures from one address across many accounts, which is the pattern of credential stuffing — and crossing a threshold records a security event and alerts a monitored address.
Step-up verification with a passkey is available, and each school decides whether to use it. Signing in is unchanged — it is password only, as before. What a school can now switch on is an extra check at the door of a few sensitive areas: organization settings and API keys, the data-rights export and erasure tooling, safeguarding and pastoral records, SIS credentials and roster sync, and the security log. A person covered by the policy is asked once for the fingerprint, face or device unlock they already use, and that confirmation lasts fifteen minutes so moving around inside the area does not ask again.
- Two independent settings, both per school: which roles must confirm (administrators, leadership, staff with access to confidential records, and other staff roles) and which areas require it. Default off for every organization.
- Students and families can never be included. The setting is keyed on staff roles, and a student holds none — so there is no value that selects them. That is deliberate: a passkey belongs to whoever owns the device, and shared class devices make that promise untrue.
- The credential never leaves the person's device. We store a public key and a credential identifier. No third party is involved in the check, there is no SMS and no authenticator app, and no new subprocessor — the subprocessor list needed no new row for this.
- The check is enforced on the server, against the live session, not by hiding a button. Enrolment, each successful and failed confirmation, and every administrator-initiated reset are recorded in the security log (section 7).
- If someone loses their device, an administrator clears their passkeys after confirming with their own, and the person is emailed that it happened. Their password is unchanged, so they are never locked out of Taonova itself — they are asked to set up a new passkey the next time they open a protected area. There is no email bypass, because a bypass would make the second factor decorative.
- Platform administration (our own cross-school operator tools) can be put behind the same check; it is enabled per installation rather than by any one school, and section 10 says plainly that it is off by default.

4. Access control and data isolation

Every read and write is authorised server-side, on the data-publication and method layer. Nothing relies on the client hiding a button.
Data access is scoped to the user's organization and role; organizations are isolated from one another.
Method arguments are validated server-side, and collection schemas strip fields they do not declare, so a request cannot smuggle extra data into a record.
Administrative capabilities are role-gated within the organization; platform operations are gated to platform administrators.

5. Uploaded files and signed links

Uploaded files — including form and collector attachments, which routinely carry medical and consent documents — are written private and served through a permission-checked redirect: the server re-runs the owning record's own read check, then issues a signed URL valid for five minutes. Journal links carry a signed, integrity-checked token, so a forged, tampered, expired or wrong-person link resolves to nothing.

6. Third-party code and where data can leave

No analytics, advertising, telemetry, session-recording or error-reporting service anywhere in the product. Verified by search, enumerated in the subprocessor list (§6).
Client-side libraries are vendored and served from the installation's own origin, and a unit test fails the build if a new CDN reference appears in client code.
Almost every outbound integration is switched on by the school, not by us, and requires the school's own API key before any data leaves the installation. The full menu, with what each provider receives, is the subprocessor list.
Where an AI provider is enabled, prompts pass through a central pseudonymisation shield that replaces people's names before anything is sent, and fails closed — if the shield cannot be built, the prompt is not sent. Names are pseudonymised; free-text content is not, and the Privacy Policy (§6) says so rather than claiming anonymity.
The outbound email relay is a per-deployment choice, disclosed on each installation's own published privacy page.

7. Monitoring and how we learn something is wrong

Taonova watches three things about itself, chosen because they are the three things this application can honestly see:

Failed sign-ins — per account, and per client address across accounts;
Data-rights volume — an unusual number of exports or erasures in a short window;
Unexpected server errors — a spike in failures that are not ordinary permission denials.

Crossing a threshold writes a security event where a person can read it, and then emails a monitored address — in that order, so a failed email cannot lose the event. What this deliberately does not include: host, network, filesystem or database monitoring, and no detection of a legitimate credential used illegitimately. Section 10 again.

Three detectors, and separately an authentication trail. The same log also records what happened with the passkey step-up in section 3: a passkey enrolled, a confirmation that succeeded or failed, a policy change, and an administrator clearing somebody's credentials. Those are records, not detectors — they raise no alarm on their own and nobody is emailed about them, with one exception: one person clearing another person's passkeys is alerted on, because it is the move an attacker makes after taking over an administrator account. The monitoring described to schools in the Data Processing Agreement clause 11 remains exactly the three detectors above.

8. If something goes wrong

If we become aware of a personal data breach affecting a school's data, we will notify that school without undue delay and in any event within seventy-two (72) hours of becoming aware, with what we know at the time: what happened, who and how many are affected, the likely consequences, what we are doing, and who to contact. We will not wait for the investigation to complete before telling the school. The binding versions of this commitment are the Terms of Service (§9), the Privacy Policy (§10) and the DPA (clause 11).

9. Development and release practice

An automated test suite covers the server method and publication layer, and an end-to-end browser suite exercises the product as a user; both run before release.
Deployments to the hosted service are health-checked before traffic is switched, and the previous version is retained so a bad deploy can be rolled back.
Dependencies are pinned; vendored client libraries are pinned to specific versions rather than tracking a CDN's latest.

10. What is not in place, and what stands in its place

Stated rather than glossed, and kept current in the same commit as the facts change. For each gap: what is missing, what stands in its place today, and where it is going. A roadmap entry here is a statement of intent, not a dated promise — we would rather ship a thing and then say so than promise a date.

No independent penetration test and no third-party certification — no ISO 27001, no SOC 2. Both cost money we currently spend on the product, so a school whose procurement requires a certificate should treat this as a firm no for now. What stands in its place: every claim on this page is written from the source code, the review copies of these documents carry file-level citations a school may request, sections 2–7 describe controls a reviewer can probe directly, and we will complete a school's own security questionnaire honestly — including the answers that are "no".
No second factor at sign-in. Passkey step-up for sensitive areas has shipped and is described in section 3 — but the front door itself is still password-only, and a stolen password still gets an attacker into everything that is not behind a step-up check. What stands in its place: passwords stored only as salted bcrypt hashes, no readable password ever created for bulk accounts, rate limiting, monitoring for both per-account and cross-account failed-sign-in patterns (sections 3 and 7), and — for schools that switch it on — a second factor in front of organization settings, API keys, data-rights tooling, safeguarding records, SIS credentials and the security log. What is coming: the same passkey, offered as a second factor at sign-in for people who have enrolled one, and later as a replacement for the password rather than an addition to it. Both reuse what has shipped.
Step-up for our own platform-administration tools is off by default. The mechanism exists and is one configuration line, but it is not switched on in a deployment unless the operator switches it on. Why it is stated rather than quietly defaulted on: platform administration is reached from whatever machine an operator is at, including a console with no fingerprint reader, and a deployment that upgraded into a lockout would have no in-product way out. Naming a default we have chosen for our own convenience is more use to a reviewer than a claim that sounds better.
No account lockout — repeated failures are rate-limited and alarmed (sections 3 and 7), not locked. We have preferred rate limiting because a lockout is a control an attacker can deliberately trigger against a named person's account. That reasoning is unchanged now that step-up has shipped, and it is revisited again when a second factor reaches sign-in itself.
No encryption at rest beyond what the hosting platform provides, and no documented key management. What stands in its place: transport encryption everywhere, private object storage behind five-minute signed URLs, and server-side authorisation on every read. A self-hosted school can place the database and file store on encrypted volumes it controls — which is also the strongest data-residency answer this product can give.
No host, network, filesystem or database monitoring — the monitoring in section 7 is application-level only, and it cannot detect a legitimate credential used illegitimately. It is the floor a small vendor can honestly operate: the three detectors it does run write durable events first and alert a monitored address second, so a mail failure delays an alert rather than losing it.
Subprocessor-change notice is manual email, not an automated mechanism (subprocessor list §7) — workable at the current number of customers, and stated so that "notice" does not imply machinery that does not exist.

11. Self-hosted installations

A school that runs Taonova itself controls — and is responsible for — the environment: hosting, database, backups, encryption at rest, network security, patching and TLS. We remain responsible for the security of the software we supply, and we will tell self-hosting customers about vulnerabilities we learn of in it. One operational note that matters: the vendored client libraries must ship with the deployed bundle, or the installation silently falls back to public CDNs for some assets (subprocessor list §4).

12. Reporting a vulnerability

Please tell us privately at info@taonova.com. We will acknowledge the report, keep you informed, and not pursue anyone who reports in good faith and does not access other people's data in the process.

Taonova is a product of Firma Limited, a company incorporated in New Zealand. Governing law: New Zealand.

New Zealand Business Number 9429036053421. Registered office: 64 Ngatiawa St, One Tree Hill, Auckland 1061, New Zealand.

Privacy questions, data-subject requests, security reports and legal notices: info@taonova.com.