For most driving schools, the best login policy is to let customers identify their account with either a verified email address or a verified mobile number—while keeping one canonical account per person. That gives families flexibility without turning every spelling difference, changed phone number, or guardian contact into a second student record.
But “both” is not automatically the safest or simplest choice. It only works when the software can normalize contact details, detect duplicate identities, verify ownership, recover an account after a phone or inbox is lost, and keep guardians separate from students. If those controls are missing, a single well-supported identifier is better than two unreliable ones.
Email, phone, or both: the short decision
| Login policy | Choose it when | Main failure to plan for |
|---|---|---|
| Email only | Most customers reliably use email, staff need a durable written channel, and password-reset delivery is dependable. | Students may use a parent’s inbox, mistype an address, or rarely check it. |
| Phone only | Your audience reliably has SMS-capable mobile numbers and phone-based onboarding materially reduces failed registrations. | Numbers change, are reassigned, are shared, or cannot receive a code. |
| Email or phone | Your system can bind both verified identifiers to one person and resolve collisions without creating duplicate accounts. | The same person can be split into two records—or two people can be merged—if identity matching is weak. |
The choice should be made from actual enrollment and support behavior, not a preference for one input field. Review how students first book, who pays, whether minors use a guardian’s contact details, which channels consistently deliver, and how staff restore access when the original channel is unavailable.
A login identifier is not the same as an authenticator
Email and phone are usually identifiers: they tell the system which account a person is trying to access. A password or one-time code is an authenticator: it is evidence that the person controls an accepted secret or channel.
This distinction matters when a vendor says it supports “phone login.” That could mean a phone number plus password, an SMS code instead of a password, or a phone number merely used to find an account before another recovery step. Those are different policies with different delivery, recovery, and security consequences.
A one-time code is also not automatically multi-factor authentication. NIST distinguishes single-factor OTP, multi-factor OTP, passwords, and out-of-band authentication as separate authenticator types. It also says manually entered OTP and out-of-band methods are not phishing-resistant. A driving school should therefore describe password-or-code access accurately instead of labeling every code flow “2FA.”
When email-only login is the better policy
Email-only login can be the cleanest choice when every student or responsible adult is expected to maintain an individual inbox. It is readable, searchable, useful for receipts and policy notices, and less likely than a phone number to be reassigned to a stranger.
It fails when the address on the student record is not really the student’s identity. Common examples include a parent’s email copied onto two siblings, a front-desk placeholder created during telephone enrollment, or a typo that is never verified. In those cases, “email required” does not create a trustworthy account—it only creates a required field.
Before choosing email only, test these questions:
- Is every address verified before it becomes a login identifier?
- Can two people legitimately share the same inbox, and if so, how are their accounts separated?
- What happens when an enrollment email bounces?
- Can the person change the address without silently creating another customer?
- Can support restore access without disclosing whether a particular email has an account?
OWASP recommends generic responses for login, registration, and recovery so an attacker cannot easily discover which identifiers exist. That means the public response should resemble “If an account matches, we sent instructions,” while staff retain enough internal detail to resolve legitimate delivery problems.
When phone-only login is defensible
Phone-only login can reduce friction for a mobile-first audience, especially when a student begins with a call, text, or quick booking form and does not have a dependable personal email address. It can also avoid fake placeholder inboxes.
The tradeoff is that a phone number is not a permanent identity. Customers switch carriers, lose devices, share family numbers, and surrender numbers that may later be reassigned. The FCC has specifically addressed SIM-swap and port-out fraud because mobile numbers are widely used in account authentication. NIST treats changing a pre-registered telephone number as binding a new authenticator, not as a harmless profile edit.
A phone-only policy therefore needs more than an SMS field:
- Store normalized numbers consistently, including country code.
- Verify the number before using it for access.
- Rate-limit code requests and failed attempts.
- Make codes short-lived and one-use.
- Provide a recovery route for a lost, changed, or unreachable number.
- Notify the customer when the bound number changes.
- Prevent a reassigned number from casually inheriting the former holder’s account.
Twilio’s current verification guidance also recommends validating phone numbers, using retry buffers, verifying each newly added contact method, and registering an additional recovery method early. Those are operational requirements, not optional polish.
Why “email or phone” is harder than two login boxes
Supporting both identifiers is usually the most forgiving customer experience. It is also the option most likely to expose weak identity architecture.
Consider a student who books by phone, then later registers with an email address. If the software cannot safely link the verified email to the existing phone-based customer, the school may get two records: one holding the package balance and another holding the portal login. The reverse error is worse: a loose match may merge two different people who share a family phone or inbox.
A sound “both” policy needs a canonical identity record underneath the contact methods. Each verified email or phone should point to that one record. New-contact changes should check for collisions, and an ambiguous match should go to staff review instead of an automatic merge.
This is particularly important in driving schools because the account may connect to appointments, permit documents, lesson credits, guardian relationships, payments, progress, and completion records. Login convenience cannot be allowed to rewrite ownership of those records.
Do not use a shared family login as a guardian model
A second email on one account is not the same as a guardian relationship. It may let two adults enter the same record, but it cannot reliably show who accepted a policy, changed a booking, uploaded a document, or requested support.
Where a parent or guardian needs access, use a separate adult account linked to the student. That preserves individual recovery, revocation, and action attribution. The distinction is explored in why guardians need their own account.
The same principle applies when a school grows beyond one operator. Login identity should remain separate from permission scope: knowing who signed in is not the same as deciding what that person may view or change. The operational consequences are covered in what changes when a driving school adds a second instructor.
How RouteOS handles the decision
RouteOS has code-grounded support for per-school choices between email, phone, both, or disabled customer identifiers, and between password, one-time code, or either credential method. Its authentication flow covers login, verification, resend, reset, setup, change, social entry, and logout rather than changing only the label on a login form.
For phone-based customers, the RouteOS phone bridge links the scheduling customer to a WordPress user while maintaining normalized, network-unique email and phone identity records. It is designed not to treat an internal placeholder address as a real deliverable inbox. The current authentication implementation also includes duplicate checks, rate limiting, one-use codes, short-lived hashed reset tokens, session rotation and revocation, and redacted operational logging.
Those controls describe implemented software behavior; they do not mean every school should enable every login mode. Phone access still depends on correct phone data and a working delivery channel. Email access still depends on deliverable addresses. Social sign-in depends on approved provider and domain configuration. And RouteOS password-or-OTP mode is an alternative-credential choice—not a claim of MFA.
RouteOS also supports distinct guardian and dependent accounts, but that model is incompatible with treating multiple family emails as interchangeable credentials for one shared person. A school moving from shared logins to guardian relationships needs an identity migration, not just a settings toggle.
A five-test login policy review
- Enrollment test: Ask which contact belongs to the actual person and verify it before account creation completes.
- Collision test: Try the same email across siblings and the same phone across family members. Confirm that the system blocks or reviews ambiguity rather than guessing.
- Recovery test: Remove access to the primary channel. The user should have a controlled alternative; staff should have a documented review path.
- Change test: Replace a phone number or email. Confirm re-verification, notification, session handling, and preservation of the original student record.
- Delivery test: Measure bounces, blocked messages, delayed codes, repeated resend attempts, and support contacts by channel before declaring one method easier.
If a staff member’s phone disappears during a workday, use the lost-phone response for account containment and lesson continuity.
Login policy should be reviewed alongside the broader driving school software buying decision. An attractive portal is not enough if access failures split records or force staff to override identity controls.
The practical recommendation
Start with email or phone as verified identifiers on one canonical account if the platform can pass the five tests above. Require a second verified recovery route where practical, keep guardians as distinct people, and use staff review for collisions.
If the system cannot do that, choose one identifier and operate it well. Email-only is usually preferable when individual, deliverable addresses are normal. Phone-only can be appropriate for a genuinely mobile-first customer base, but only with robust number-change and recovery handling. The wrong choice is “both” implemented as two disconnected ways to create records.
Sources
- NIST SP 800-63B: Authentication and Authenticator Management
- OWASP Authentication Cheat Sheet
- FCC report and order on SIM swapping and port-out fraud
- Twilio verification and authentication best practices
Product behavior reviewed September 5, 2026 against the supplied RouteOS code-grounded feature report. Security references were also reviewed September 5, 2026.