School data carries real consequences. We build like it does.
Student profiles, fee transactions, attendance and exam results sit behind role-based permissions, authenticator-app MFA, session control, tenant-level data separation and audit logging not a paid security bolt-on.
Why this page exists
Schools hold the most sensitive data there is, and almost none of it is optional
A school system holds records of minors, guardian contact details, family financial history and academic performance. None of it can be deleted to reduce risk a transfer certificate needs the history, and a fee dispute needs the ledger. So the only workable answer is to control who can reach what, prove what happened, and keep one school's data out of another's reach.
Security in KIDUART is not a paid add-on. It is a functional area like any other, with its own workflows and controls, and it applies to every panel from the system admin console down to a parent checking one child's attendance.
See the security module area- SixDefence layersLogin to audit stacked, not bolted on
- Role-basedAccess controlTeachers, finance and parents see only their desk
- Per schoolData isolationEach campus stays in its own tenant
- AuditedSensitive actionsMarks, fees and permissions leave a trail
The short version
Verified logins with optional authenticator-app MFA, permissions decided by role, each school in its own tenant database, sessions you can revoke, optional IP and location fencing, and an audit trail for sensitive actions.
Threats, translated into school situations
What happens when a password leaks, a teacher leaves, or a mark changes quietly?
Work through every scenario. Each answer points to the exact defence layer and the controls that exist in the product today.
- defence layers
- Sixdefence layers
- access control
- Role-basedaccess control
- data isolation
- Per schooldata isolation
Controls that exist today no certification we have not earned.
Pick what worries you
What is being attempted
Someone takes an email and password from an unrelated breach and tries it on your parent portal, hoping the family reused it.
Which layer answers it
- 01IdentityHandles this scenario
- 02Roles
- 03Isolation
- 04Sessions
- 05Perimeter
- 06Audit trail
Layer 01 · Identity and login
Every login is a verified person, not a shared password on a staffroom notice
What KIDUART does about it
Passwords are stored hashed with bcrypt, so a KIDUART database dump would not hand anyone a usable password in the first place. Repeated failed attempts lock the account, and staff accounts that handle money or marks can be required to pass an authenticator-app code before the login completes.
- Password hashing with bcrypt no plain-text password is ever stored
- Account lockout after repeated failed login attempts
- Authenticator-app (TOTP) multi-factor with recovery backup codes
What is being attempted
Their last day passes, but their login still exists and in most schools nobody remembers to check what it can still open.
Which layer answers it
- 01Identity
- 02Roles
- 03Isolation
- 04SessionsHandles this scenario
- 05Perimeter
- 06Audit trail
Layer 04 · Sessions and devices
A forgotten login on a shared computer can be ended from anywhere
What KIDUART does about it
Deactivating the user ends access rather than just hiding a menu. Their sessions can be revoked from the admin side, refresh tokens are invalidated instead of quietly living on, and if they signed in with a school Google or Microsoft account, disabling that account closes the second route too.
- Revoke a single session, all other sessions, or everything
- Refresh-token rotation with revocation support
- Token invalidation on logout
What is being attempted
An automated script runs thousands of password attempts against the school login, usually at night when nobody is watching.
Which layer answers it
- 01Identity
- 02Roles
- 03Isolation
- 04Sessions
- 05PerimeterHandles this scenario
- 06Audit trail
Layer 05 · Access perimeter
Admin access can be fenced to your campus network when you want it
What KIDUART does about it
Authentication routes carry stricter rate limits than the rest of the API, so the script is throttled before it gets anywhere, and the account it is targeting locks itself. Schools that want a harder boundary can restrict admin access to campus IP ranges or an approved region.
- Rate limiting on the API, with stricter limits on authentication
- IP allow list and block list
- Geo-restriction for location-based access rules
What is being attempted
The classic multi-tenant worry: one customer's admin finds a way to query another customer's students because everything sits in one shared table.
Which layer answers it
- 01Identity
- 02Roles
- 03IsolationHandles this scenario
- 04Sessions
- 05Perimeter
- 06Audit trail
Layer 03 · School data isolation
One school's records cannot be queried from another school's login
What KIDUART does about it
Each school's data lives in its own tenant database rather than sharing rows with everyone else, and the tenant is resolved before any query runs. The boundary is structural, so it does not depend on a developer remembering to add a filter.
- Tenant-per-school database separation
- Tenant resolved on every request before data access
- Campus-wise reporting without merging campus data
What is being attempted
An accountant opens exam marks. A class teacher browses the fee ledger. Not malicious, usually just possible, in most school software.
Which layer answers it
- 01Identity
- 02RolesHandles this scenario
- 03Isolation
- 04Sessions
- 05Perimeter
- 06Audit trail
Layer 02 · Roles and permissions
A class teacher never sees the fee ledger, and an accountant never sees exam marks
What KIDUART does about it
Access is decided by role, not by trust. Each role carries explicit permissions and gets its own sidebar, so people do not navigate to screens they cannot open. An organisation can restrict what a school admin is allowed to grant, but never let them expand their own access.
- Role-based permissions across every module area
- Role and permission delegation from organisation to school
- Unified role-based sidebar menus reflect real permissions
What is being attempted
A parent disputes a receipt, or a student's grade does not match the answer sheet, and the office has no way to prove who touched it.
Which layer answers it
- 01Identity
- 02Roles
- 03Isolation
- 04Sessions
- 05Perimeter
- 06Audit trailHandles this scenario
Layer 06 · Audit trail and API access
When someone asks who changed a mark or a fee entry, there is an answer
What KIDUART does about it
Sensitive actions logins, MFA changes, password resets, permission changes and financial events are written to an audit log. When the question comes months later, there is a record to answer it with instead of a memory of who was on duty.
- Audit logging for authentication and sensitive record changes
- Payment gateway webhooks verified before they are processed
- Encrypted storage for third-party integration credentials
What is being attempted
Your website developer or reporting vendor asks for 'an admin account' and now a third party holds a staff password with full access.
Which layer answers it
- 01Identity
- 02Roles
- 03Isolation
- 04Sessions
- 05Perimeter
- 06Audit trailHandles this scenario
Layer 06 · Audit trail and API access
When someone asks who changed a mark or a fee entry, there is an answer
What KIDUART does about it
They get a scoped API key instead, limited to what that integration genuinely needs and revocable on its own. Nobody has to share a staff password, and when the contract ends you revoke a key rather than changing everyone's login.
- Managed API keys with scoped access instead of shared credentials
- Audit logging for authentication and sensitive record changes
- Encrypted storage for third-party integration credentials
Defence in depth
Six layers between a login screen and a student record
Read them the way a request travels: someone signs in, their role is checked, their school is resolved, their session is tracked, the network they came from is evaluated, and whatever they change is written to the log.
6 layers, outside in
Each plate is a separate control. A gap in one does not open the record underneath it.
Layer 01 · Core Authentication
Identity and login
Every login is a verified person, not a shared password on a staffroom notice
Login is the widest door in any school system, so it carries the most controls. Accounts verify email and phone, passwords are stored hashed with bcrypt, failed attempts lock an account, and staff can add an authenticator app as a second factor. Google and Microsoft sign-in are supported where a school already runs those accounts.
- Universal login for staff, teachers, students and parents
- Password hashing with bcrypt no plain-text password is ever stored
- Authenticator-app (TOTP) multi-factor with recovery backup codes
- Account lockout after repeated failed login attempts
- Password reset and recovery with expiring links
- Google and Microsoft sign-in for schools already on those accounts
Layer 02 · Roles & Permissions
Roles and permissions
A class teacher never sees the fee ledger, and an accountant never sees exam marks
Access is decided by role, not by trust. Roles carry explicit permissions, and permissions can be delegated downward an organisation can restrict what a school admin is allowed to grant, but never expand it. Each role also gets its own sidebar, so people only navigate to what they can actually open.
- Role-based permissions across every module area
- Role and permission delegation from organisation to school
- A 'my roles and permissions' view so staff can see their own access
- Unified role-based sidebar menus reflect real permissions
- Separate panels for organisation, school, teaching, finance, parent and student roles
Layer 03 · Access Control
School data isolation
One school's records cannot be queried from another school's login
KIDUART is multi-tenant by design: each school's data lives in its own tenant database rather than sharing rows in one common table. Requests are resolved to a tenant before any query runs, which keeps the boundary structural instead of relying on a filter someone might forget.
- Tenant-per-school database separation
- Tenant resolved on every request before data access
- Organisation-level grouping for trusts running multiple campuses
- Campus-wise reporting without merging campus data
Layer 04 · Session & Tokens
Sessions and devices
A forgotten login on a shared computer can be ended from anywhere
Sessions are tracked, not just issued. Staff can see where they are signed in and end other sessions; tokens can be refreshed and revoked, and logging out invalidates the token rather than only clearing the browser. Concurrent session limits apply per role.
- Active session list with device and last-used detail
- Revoke a single session, all other sessions, or everything
- Refresh-token rotation with revocation support
- Token invalidation on logout
- Concurrent session limits per role
Layer 05 · Access Security
Access perimeter
Admin access can be fenced to your campus network when you want it
For schools that want tighter control, access can be restricted by IP or by location, so sensitive panels are only reachable from the campus network or an approved region. Request rate limits and standard hardening sit in front of the API for every school, whether or not those optional restrictions are switched on.
- IP allow list and block list
- Geo-restriction for location-based access rules
- Rate limiting on the API, with stricter limits on authentication
- Standard HTTP hardening and input sanitisation
- OTP and authentication message templates managed in-product
Layer 06 · API Access
Audit trail and API access
When someone asks who changed a mark or a fee entry, there is an answer
Sensitive actions logins, MFA changes, password resets, permission changes and financial events are written to an audit log. Where a school needs to connect another system, access goes through managed API keys rather than sharing a staff account password.
- Audit logging for authentication and sensitive record changes
- Managed API keys with scoped access instead of shared credentials
- Payment gateway webhooks verified before they are processed
- Encrypted storage for third-party integration credentials
How we handle school data
Four rules we hold ourselves to
These are the same principles written into our privacy policy stated here in plain language so your IT reviewer does not have to read legal text to understand them.
Collected because a school workflow needs it
We store the data the modules you switch on actually require: admission and student records, guardian contacts, attendance, marks, fee transactions, staff records, and transport or hostel allocation where those areas are in use.
Visible to the roles that need it
A parent sees their own children. A class teacher sees their classes. An accountant sees the fee book. Access follows the same role and permission rules the rest of the product uses.
Retained while your school needs the record
Academic and financial history is retained because schools are required to keep it transfer certificates and fee records are the obvious example. Operational logs are kept for a limited window for troubleshooting and review.
Removed when you ask
On termination, we export your records for you and then remove school data from our active systems, keeping only what the law requires us to keep.
What we do not claim
The honest boundaries of our security story
Most vendor security pages read the same. This section says what is not true yet, because that is the part your IT reviewer actually needs.
We do not claim certifications we have not completed
KIDUART is a growing product. We describe the controls that exist in the platform today and are happy to walk your IT reviewer through them on a call. When formal audits and certifications are completed, they will be published here with dates not implied earlier.
Some controls are optional by design
IP allow lists and geo-restriction are powerful but disruptive if misconfigured, so they stay off until your school asks for them. We enable and test them with you rather than switching them on silently.
Multi-factor is authenticator-app based today
Second-factor login uses an authenticator app (TOTP) with backup recovery codes. SMS-based second factor is on the roadmap and will be announced when it ships, rather than listed as available now.
Your data stays yours
Student records, fee ledgers, attendance and exam data can be exported in standard formats whenever you ask, including if you decide to leave. We do not sell school data or use student records to train anything.
Bring your IT reviewer to the demo
We will walk through login controls, role permissions, session handling, data separation and audit logging on screen and answer what we have not built yet just as directly.
30-minute walkthrough
Booked around your school hours
Run on your own data
Your fee heads, classes and staff roles
No card, no lock-in
Nothing is charged to see the product