A guardian should not need the student’s password to help manage driving lessons. A sound guardian driving school portal gives the adult a separate sign-in, links that identity to the correct student, and checks what the guardian may do for that student on every action. This preserves who booked, changed, paid, or messaged; it also lets the school change or remove the guardian’s access without resetting the student’s account.
The important distinction is not “two usernames instead of one.” It is two people, one explicit relationship, and permissions attached to that relationship. NIST describes identity and access management as getting the right people the right access to the right resources at the right time. For a driving school, the “resource” may be a student’s bookings, payment history, messages, pickup details, or progress—not the student’s entire account. See the NIST identity and access management overview.
A shared login erases the fact the school needs most: who acted
Suppose a lesson is cancelled from an account used by a student and two adults. The system may record the account and time, but it cannot reliably tell the school which person made the decision. If a message says “Please move the road test,” staff cannot tell whether the student wrote it or a guardian did. If the password is changed, every person using that account may be locked out at once.
This creates four avoidable failures:
- Attribution fails. The audit trail identifies an account, not the person who took the action.
- Authority becomes all-or-nothing. Anyone with the password inherits whatever the student account can do, even if the adult only needs to schedule or pay.
- Recovery becomes shared. A reset intended for one person can disrupt everyone, and the recovery destination may belong to the wrong family member.
- Access cannot change cleanly. Removing one adult means changing the student’s credentials and redistributing them to everyone who should remain.
A longer or stronger shared password does not solve those problems. Password strength helps protect a credential; it does not turn one credential into several attributable identities. OWASP defines authentication as checking who an individual or entity claims to be and recommends re-authentication around recovery and sensitive account changes. Those controls work properly only when the account has a clear owner. See the OWASP Authentication Cheat Sheet.
The portal should authorize the relationship, not just the login
A separate guardian login is necessary, but it is not sufficient. After sign-in, the software still has to answer: “Is this adult connected to this student, and is this action allowed through that connection?” That is relationship-based access.
| Event | What the system must preserve | What a shared student login loses |
|---|---|---|
| Guardian sends a message | Adult identity, relationship label, student thread, time, and content | The message appears to come from the student account |
| Guardian views or changes a booking | Which student was selected and whether that guardian may perform the action | Possession of the password becomes the only practical test |
| Guardian loses access | Revoke one relationship while preserving the student and other guardians | The school must rotate a shared credential |
| Guardian forgets a password | Recover the guardian’s account through the guardian’s verified channel | Recovery can take over or disrupt the student’s account |
OWASP’s authorization guidance recommends defining user types, resources, and allowed operations, applying least privilege, and testing permissions on every request. It also describes relationship-based access as appropriate when access depends on a connection such as family membership. For a portal, that means hiding a button is not enough; the server must reject an unauthorized request even if someone changes a URL or sends it outside the normal interface. See the OWASP Authorization Cheat Sheet.
How RouteOS models guardian access
The inspected RouteOS code snapshot dated September 2, 2026 implements this as a distinct-account model in Guardian & Dependent Access 0.1.0. A guardian and student remain separate WordPress/LatePoint identities connected by a many-to-many relationship. One guardian can be linked to several dependent students, and one student can have several guardians, without merging the student records.
The implemented workflow uses bounded invitations and authenticated acceptance rather than treating a matching phone number, email address, or home address as authority. The school can configure an age below which a supported save flow requires at least one guardian relationship; the default in the inspected code is 18. That setting is an operating rule, not proof of legal custody or identity. RouteOS uses the canonical Student Information date of birth for the rule, while the school remains responsible for any relationship verification its policy requires.
Guardian messaging also preserves the speaker. When a connected adult writes in a dependent’s booking conversation, the stored message keeps an immutable display snapshot such as the adult’s name and relationship instead of presenting the words as though the student sent them. The reviewed scope is deliberately limited: guardian access does not become unrestricted control of the student account, does not let a guardian upload an attachment as the dependent, and does not create separate unread receipts for every guardian.
This capability is implemented in the inspected source; it should not be described as enabled for every RouteOS school. It also has a deployment boundary: the Guardian Access plugin pauses when the older Multi-Email Login shared-account model is active. Existing email aliases must be migrated and that incompatible plugin deactivated before the distinct-person guardian model can run. A school should choose one identity model deliberately rather than allowing both to compete.
Four portal tests reveal whether the separation is real
Do not judge a guardian portal from a dashboard screenshot. Run these tests with a test student and test guardian:
- Connect without sharing. Create or invite the guardian without giving them the student’s password. Confirm that a matching contact detail alone does not silently grant access.
- Test the wrong student. While signed in as the guardian, try to open another student’s record by changing a link or identifier. The server should deny it, not merely hide the student in navigation.
- Trace one action. Send a message or perform another permitted action. The staff view and audit record should identify the guardian, the student relationship, and the action rather than attributing it to the student.
- Remove and recover independently. Revoke the guardian relationship and confirm access ends without changing the student’s password. Then test guardian account recovery and confirm it does not reset or take over the student’s identity.
If the portal passes only the first test, it has separate credentials but not necessarily separate authority. The relationship and permission checks are the part that prevents one valid login from becoming access to every student record or every customer action.
Keep account design separate from disclosure policy
A distinct guardian account answers who is acting and which relationship permits access. It does not decide every fact the school should disclose, prove a family relationship by itself, or determine the legal rights of an adult in every situation. Those are separate policy and verification decisions.
The RouteOS guide on what to tell a parent after a teen’s lesson addresses the disclosure boundary. The student journey guide explains how identity, evidence, entitlements, bookings, and next actions connect across the learner’s progress. Owners comparing the wider system can use the driving school software buyer’s guide.
The practical decision is simple: if a parent or guardian needs to help, give that person an attributable account linked to the student and grant only the actions the relationship requires. Do not make the student’s password carry identity, consent, payment, scheduling, messaging, and recovery for an entire family.
Product implementation reviewed against the RouteOS code-grounded report snapshot dated September 2, 2026. NIST and OWASP guidance checked September 3, 2026. RouteOS feature activation and school policy are configuration-dependent.