Security and privacy
Cenovel runs on your district’s own appliance, needs no internet access and holds no student data. Here is who secures what, and how.
Updated October 4, 2026
Who secures what
Cenovel is software your district installs and runs. It is reachable only on your network, and Cenovel the company has no access to it, or to your data, unless you grant access for a support case.
- Your district secures the environment: the hosts and the appliance VM, network placement and firewall rules, remote access, your directory and MFA policies, who holds which Cenovel role, device credentials, backups and the backup keyring, and installing security releases promptly.
- Cenovel secures the software: secure development with dependency and secret scanning, a software bill of materials with every release, signed releases and site collectors, timely security fixes, and the hardening guidance in the documentation.
Your data stays on your network
- Inventory, topology, device reads, work records and E-Rate records are stored and served on the appliance.
- The appliance needs no internet access. It sends no telemetry, makes no update check and does not phone home. The license is checked on the appliance, offline.
- It connects out only to what you configure: your devices, your directory or Microsoft Entra ID, email, webhooks, site collectors and an off-box backup host.
No student data
Cenovel models equipment, places and staff accounts. It holds no student records: no names, IDs, grades or enrollment records, and students never sign in. The one student-related value is an enrollment count per site, a single number the E-Rate Category 2 budget needs.
Sign-in and roles
- Staff sign in with Active Directory over LDAPS or StartTLS, never plain LDAP, with optional authenticator codes; or with Microsoft Entra ID. Directory passwords are checked by the directory and never stored or logged.
- Someone in no mapped directory group cannot sign in. Removing a person from a group ends their access within minutes.
- Access tiers, page permissions and department scope decide what each person can see and change. A local recovery account, created at first boot, always works.
Encryption, backups and the audit trail
- The console is served over HTTPS only, with your district’s certificate or the appliance’s own authority.
- Secrets the console stores, such as device credentials, are sealed with the deployment’s settings key, which you can rotate.
- Backup sets are encrypted and authenticated. Keep the backup keyring apart from the backups, send a copy off the appliance, and use the restore drill to prove a set restores.
- Every change is recorded in an audit trail with an integrity chain you can verify and export.
Signed releases
- Release bundles are signed. The installer and the updater check the signature against a trusted public key before anything is staged, and refuse a bundle that fails.
- Site collectors run only a release signed by the Cenovel release key, which is kept offline.
- Upgrades run preflight checks and a readiness gate, and each district installs releases on its own schedule.
Report a vulnerability
Write to [email protected]. A person reads every report. Fixed vulnerabilities are published as security advisories, and the previous major version gets security fixes for 12 months after the next one ships.
Questionnaires and agreements
We answer district security questionnaires and sign data privacy agreements. Ask on the trial call, or write to [email protected].
See also: Security & data in the documentation · Incident and breach response · Directory sign-in