Tera — Security Fact Sheet

Security in Tera is not a module you switch on — it is the foundation the whole platform is built on. The design brief was a college holding the data of young people, some of them minors, under real regulatory duty. Every decision below flows from that: assume the data is sensitive, prove every access, keep an unalterable record, and store nothing an attacker could quietly steal.

API keys, connection strings or passwords stored in the platform

100%

of sign-ins on a hardened, isolated identity domain

WORM

immutable audit trail — no one can alter or delete it

data hosted onshore; it never leaves the country

Identity & authentication

Every person is verified by Microsoft's identity cloud before they touch a single record.

Keyless, secret-free authentication end to end. The platform holds no API keys, connection strings or service passwords — anywhere. Every service authenticates with a managed workload identity verified by Microsoft Entra ID. There is nothing to leak, rotate or steal.
Passwordless-first sign-in. Students and families sign in with email one-time codes and multi-factor authentication, not reusable passwords. Fewer passwords means fewer breaches.
A dedicated, hardened sign-in domain (Tera Shield). Every sign-in happens on one trusted address, isolated from the applications — one place to trust, and one place to defend.
Tokens never reach the browser. Each app runs a Backend-for-Frontend: the server holds the session and access tokens and proxies requests on the user's behalf. A compromised browser tab has no token to steal.
Certificate-based app identity. Application credentials are certificates held in Azure Key Vault and read by a managed identity — never a secret pasted into code or config.
Separate directories for students and staff. End users live in a dedicated customer identity tenant, kept entirely separate from staff/workforce identity — with a separate directory for each environment.
Multi-factor and Conditional Access. MFA on staff access, with the ability to require step-up verification based on risk, location or device.

What this means for you: there are no shared logins and no stored secrets. Access is a verified person, every time — and losing a laptop doesn't lose your data.

Authorisation & tenant isolation

Your college's data is walled off from every other college's — and every request must earn its access.

Deny by default. Nothing is accessible unless a rule explicitly allows it. Every request must prove which college it belongs to and that the caller holds the right role, or it is refused.
Tenant identity is stamped server-side, never trusted from the request. Which college you're acting in is resolved at the edge and applied by the server — a client cannot claim to be another college by editing a request.
Physically partitioned data. Records are partitioned by college at the database level; a query for one college can never fan out into another's data.
Role-based access control. Granular, per-college roles (member, writer, administrator, plus care-specific roles) govern who can see and change what.
Data-plane access is separate from management access. Holding an Azure management role does not grant read access to college data — reading records requires a distinct, explicitly granted data role.
Optional dedicated infrastructure. Enterprise colleges can run on a fully isolated, dedicated cloud subscription. Isolation is a deployment choice — never a fork of the software.
Locked-down internal surfaces. Care records (wellbeing, pastoral) sit behind their own access door; only the people who must see them can, and emergency ("break-glass") access always leaves a trace.

What this means for you: your data is yours alone. Even inside our platform, no other college — and no over-broad administrator — can reach it.

Encryption

Protected in motion and at rest, on modern standards.

Encrypted in transit. All traffic is TLS-encrypted — TLS 1.3 on the web tier, TLS 1.2 or higher everywhere else. Plain-text connections are refused.
Encrypted at rest. All stored data is encrypted at rest with AES-256 by the Azure data platform.
Encrypted sessions and caches. Sign-in cookies and the server-side token cache are encrypted with keys held securely and shared safely across instances.
Strict transport security. HSTS is enforced, so browsers will only ever connect over HTTPS.

Audit & accountability

An unalterable record of who did what — including us.

Tamper-proof audit trail (WORM). Every sensitive read and write — including staff access to care records — is recorded and mirrored to Write-Once-Read-Many immutable storage. Within the retention window, the record cannot be altered or deleted by anyone. Not your staff. Not ours.
Traced break-glass access. Emergency access to sealed records is possible when a duty of care demands it — and it is always logged, attributed and reviewable.
Audited support access. When our team acts on your behalf to help, it is done through a time-boxed, fully audited "view-as" mechanism recorded against the real person — never a shared back door.
Consent recorded once, honoured everywhere. Consents and their withdrawal are captured in a durable ledger and enforced consistently across the system.
Full telemetry. Requests, dependencies and errors are instrumented end to end for security monitoring and incident investigation.

What this means for you: when the auditor, the board or a parent asks "who accessed this?", the answer exists, it's complete, and it cannot have been tampered with.

Application hardening

The everyday defences that stop common attacks before they start.

No personal data in logs. Records are identified in logs by stable identifiers only; where an email is genuinely needed it is masked. Names, addresses and minors' details never appear in a log.
No personal data to third parties. Nothing about a person is sent to outside services — for example, profile images are generated and self-hosted, never fetched from an external avatar service.
Strict Content Security Policy. Browsers are forbidden from loading any external or inline scripts, sharply limiting cross-site scripting. No third-party CDN or tracker is trusted.
Clickjacking, MIME and referrer protections. X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict Referrer-Policy and a minimal Permissions-Policy on every response.
Validated, bounded input. Every field is length- and format-checked, and request bodies are capped — oversized or malformed input is rejected outright, never stored.
Rate limiting. Public sign-in and gateway endpoints are throttled to blunt brute-force and abuse.
Safe error handling. Errors return structured, standards-based responses — never a stack trace or an internal detail an attacker could use.
Reliable, non-duplicating writes. Financial and record changes use transactional, idempotent processing and optimistic concurrency, so nothing is silently double-applied or overwritten.

Hosting, infrastructure & supply chain

Where it runs, how it's built, and how we keep the pipeline clean.

Hosted onshore in Australia. Your data is stored in Australia and does not leave the country.
One managed identity per workload. Each component runs as its own dedicated managed identity with least-privilege access — never shared, never over-scoped.
Everything as code, deployed keylessly. Infrastructure is defined in code and deployed through a pipeline that authenticates by federated workload identity — there are no stored deployment credentials.
Continuous backup with point-in-time restore. Data stores are continuously backed up and protected against accidental or malicious deletion.
Locked, reproducible dependencies. Third-party libraries are version-pinned and verified in the build, closing off supply-chain tampering.
Enforced quality gates. Static analysis runs on every change with warnings treated as errors — including a custom check that automatically blocks any code that would log personal data.

Privacy by design

Built for the Australian Privacy Principles and the sensitivity of college life.

Built to the Australian Privacy Principles. Data handling is designed around the APPs from the ground up, for an organisation holding minors' and health information.
Data minimisation and retention. We collect what a college needs, and retention and deletion are managed rather than left to accumulate forever.
Your data is yours. Export everything at any time in open formats. If you ever leave, you take your data with you and the tenant is verifiably decommissioned.
Least-exposure by default. Sensitive information is shown only to the roles that need it, and never rendered where it isn't required.

What this means for you: you meet your obligations to students and families by default, not by bolting on a policy after the fact.

Resilience & the managed service

Kept running, patched and watched — so you don't have to.

Highly available by design. The platform runs across multiple instances with a shared, distributed session store, and health checks that route around trouble.
Fully managed by us. On the managed service, our team runs, patches, backs up and monitors your environment around the clock — the security operations most small colleges can't staff themselves.
Secure onboarding. New colleges are provisioned through a keyless, application-only, audited process — never a shared database or a manual credential hand-off.
Responsible disclosure. We welcome security reports and act on them quickly — get in touch and we'll route it to the right people.