Security

Encryption in transit

Every connection to 1410SMS is served over HTTPS/TLS. That covers the school portal, the student and parent portals, and the mobile app. Subdomains (e.g. yourschool.1410sms.com) are covered by a wildcard certificate, and custom domains are provisioned automatically through Cloudflare for SaaS, so a school pointing its own domain at its portal gets a valid certificate without managing one itself. Unencrypted requests are not served.

Password security

Passwords are never stored in plain text. Every password, whether it belongs to a member of staff, a student or a parent, is stored using a one-way cryptographic hash. Not even we can read one back out of the database. Student accounts default to a system-generated password (their admission number) which we recommend changing; staff and parent accounts always set their own.

Role-based permissions

Access is scoped to what an account actually needs. The platform recognises five distinct actor types (school admin, teacher, student, parent, and a short-lived guest identity for entrance-exam candidates), each with its own permitted actions. Those permissions are enforced on every request rather than merely hidden in the interface. Within a school, admin accounts can be tiered further: a primary admin can manage other admin accounts, while a regular admin has full teaching-feature access without the ability to create, edit, or deactivate other admins. A school can never lose its last primary admin by accident.

Audit logging

Sensitive actions are recorded in an audit log with the acting user, a timestamp and the originating IP address, so your school has a record of who did what and when. That covers administrative changes, subscription overrides and support impersonation. Audit logs are visible to school admins from within the dashboard.

Infrastructure security

The platform runs on cloud infrastructure behind a managed edge network that terminates TLS and shields the application from common network-level attacks. We do not publish detailed infrastructure diagrams or provider-specific configuration publicly, in line with standard practice. It is available to prospective enterprise customers under a mutual agreement where appropriate.

Server monitoring

Application health is monitored continuously: database connectivity, background job queues and system resource usage, with automated error tracking on unhandled exceptions. The point is that we find out about problems before a school has to tell us.

Disaster recovery

Recovery from an infrastructure failure is covered in detail on our Backups & Disaster Recovery page.

Security updates

Dependencies and the underlying platform are kept up to date, with security-relevant updates prioritised over routine ones. Schema and infrastructure changes go through a review step before release, and we favour reversible, incremental changes over large untested ones.

Responsible disclosure

If you believe you've found a security vulnerability in 1410SMS, please tell us directly using the Contact Security Team button below rather than disclosing it publicly. We don't yet run a formal bug bounty programme, but we investigate every report we receive and will acknowledge it. Please give us a reasonable opportunity to investigate and address an issue before sharing details with anyone else.

Planned features