Security

1. Hosting and network

• The application, database, cache and logs run on one dedicated virtual server hosted by Hetzner in Helsinki, Finland (EU). Off-server backup copies and the keys described in section 4 are in Microsoft Azure in Sweden (EU). The documentation site and student portal are static sites served by Cloudflare.
• The server accepts no inbound web traffic. All web requests reach it through an outbound-only encrypted tunnel to Cloudflare, which applies a web application firewall and DDoS protection before forwarding a request. No application container publishes a port.
• The hosting provider's firewall admits no inbound web traffic, only administrative SSH. Administrative sign-in uses SSH keys; password sign-in and direct sign-in as the system administrator account are disabled, and repeated failed sign-ins are blocked automatically.
• Inside the server, a router exposes three sites through the tunnel: the API (only its public routes, and only through its gateway), the administrator portal, and the log service, which is also behind Cloudflare Access. The database and the caches are reachable only on the server's internal network.

2. Encryption in transit

• Every connection from a browser or a partner system uses TLS, terminated at Cloudflare. Cloudflare reaches the server only through the encrypted tunnel.
• The server's calls to sign-in, AI, email, storage and key services use TLS. Backup uploads use HTTPS only, and the storage account refuses anything older than TLS 1.2.
• Traffic between the application's own containers stays on the server's internal network and is not separately encrypted.

3. Encryption at rest

• Server storage. The application's data (the database, the caches, the application logs, the local backups, the application's configuration and secrets, and the container images) is stored on one encrypted volume: LUKS2 with AES-XTS (aes-xts-plain64, a 512-bit key), its passphrase protected by the Argon2id key-derivation function. The unencrypted copies made before encryption was turned on were deleted on 2026-11-11 and the freed disk blocks were discarded; that cannot reach copies the hosting provider may hold from before then. The server's operating system disk, including its system logs, is not on the encrypted volume and holds no application data.
• Off-server backups. Azure Storage encrypts the backup copies at rest with AES-256 (Microsoft-managed keys).
• Sign-in cookies and protected values. The keys that protect administrator sign-in cookies and other protected application values are stored in Azure Storage and wrapped by a key held in Azure Key Vault.

4. Keys and secrets

• The storage key never lives on the server's disk. It is a random 256-bit value generated by a cryptographic random number generator and stored only in Azure Key Vault, which has purge protection on, grants access by role, and has a firewall that admits only the server's network address. It is read into the server's memory only to create or unlock the volume, or for a weekly check that it still unlocks it, and is never written to the server's disk or printed.
• After any restart, the server unlocks its data automatically. It proves its identity to Azure with a certificate whose private key was created on the server and never leaves it. That identity can read only the storage key, and only from the server's own network address, so a copy of the server's disk started from any other network address cannot fetch the key, and without the key it cannot read the data. A successful automatic unlock is reported to our support team by email. A failed one leaves the service unavailable until an authorized operator unlocks it.
• Apart from the server's unlock identity, reading the storage key requires an operator's Azure account, and the key vault's firewall must first be opened to that operator's network address for the read. The server's other Azure identity cannot read it: it can use only the AI service, the key that wraps the cookie-protection keys, and the storage that holds those keys.
• Application secrets are never kept in source code. They are held in the server's configuration on the encrypted volume, readable only by the account that runs the service and the server administrator, or in the deployment system's secret store.
• The backup upload credential can only create new backup files. It cannot read, list, overwrite or delete them, so a leaked credential cannot replace or remove a good backup.

5. Backups and recovery

• The database is backed up every night while the service keeps running. Each backup's file integrity is checked before it is kept, and a copy is uploaded to Azure Storage with an integrity check in transit.
• The server keeps its two newest nightly backups. The off-server copies are deleted automatically after 13 days and then stay recoverable for 7 more days (soft delete), so a backup is normally gone within 21 days.
• Every week an automated test restores the latest backup into a separate, temporary database and checks that the core tables hold data. Every deployment takes a fresh backup before it changes the database.
• Erased information may remain in backups until they expire, as the Privacy Policy describes.

6. Identity and access

• Users sign in through Microsoft Entra External ID. We never receive or store a password.
• Every request is authorized by role (student, independent learner, teacher, institution administrator, platform administrator), and access to an Institution's data is limited to that Institution's own members and administrators. A platform administrator is the only role that can act across Institutions.
• Access to key student records is logged.
• Administrative access to the server and the cloud accounts is limited to the operator. The log service is protected by Cloudflare Access in addition to its own sign-in, and only the operator and the operator's automated diagnostics account can reach it.

7. Application protections

• An enforced content security policy on the portals, which allows scripts only from our own sites and Cloudflare's cookieless analytics.
• Request rate limits per user and per partner client, shared across the API's instances, and Turnstile abuse checks on public forms.
• Partner and integration tokens are signed by keys that are rotated automatically, and webhook messages are signed so receivers can verify them.

8. Logging and monitoring

• Application logs, traces and metrics go to a self-hosted log service on the same encrypted server and are kept there for 14 days.
• Each deployment is checked by an automated health gate and by a functional test of the live service before it is accepted.

9. Vulnerability management

• Every deployment, and every proposed code change, is blocked if a .NET package it ships has a published high or critical security advisory, unless that advisory has been reviewed and recorded as not applicable, with a written reason.
• The server installs operating-system security updates automatically.
• Every code change is reviewed independently before it is merged, and changes to security, encryption, access control or infrastructure get additional review rounds.

10. AI and other service providers

The providers that process data for the Service, what each receives, and where it processes it are listed in the Privacy Policy, section 8. AI processing is described in section 5.

11. Incidents and reporting a vulnerability

If we learn of a breach affecting personal information, we notify the affected Institutions and people, and regulators where the law requires it; Privacy Policy section 13 sets out our commitments to Institutions, including the notice period.

To report a security vulnerability, email [email protected]. Please do not access or change data that is not yours while testing.