Why phone verification is the durable path

When choosing a verification method for guest Wi-Fi there are two questions: does it work today, and will it still work in three years? Most methods answer "yes" to the first. The second one separates them. This post explains why methods that depend on an external identity lookup service are fragile, and why phone verification is a path that lasts.

Two kinds of verification

Guest verification methods fall roughly into two groups:

Externally dependent verification. The guest enters a piece of information; to verify it, the system goes to an identity database or lookup service outside the business. If the answer is "yes", the session opens. The business depends on that service being reachable, permitted and running under the same rules.

Operator- or business-backed verification. The guest already holds a channel: a phone number, an e-mail address, a coupon issued by the business, or an account opened earlier. Verification means sending a code to that channel and getting it back. There is no "identity lookup" in the middle; only proof that you control the channel.

Where externally dependent methods break

A login method built on an external lookup service can break in four places:

1. Access rules change. The service may restrict access to certain types of organisation, require a contract, add a fee or shut down altogether. That day, your portal stops issuing codes.
2. The service goes offline. When the external service does not answer, guests cannot connect. The fault is not yours, but the complaint comes to you.
3. Data minimisation gets harder. An external lookup needs more data from the guest. Under KVKK the business, as data controller, is accountable for that data; collecting more than you need is a hard choice to defend.
4. Foreign guests are left out. A local identity database does not know a foreign guest; you need a second method anyway.

We are not saying these methods turn bad overnight. We are saying they carry a dependency outside the business's control, and building your Law 5651 record-keeping on top of that dependency is a risk.

Why a phone number is different

A phone number is a channel an operator has assigned to a subscriber. The SMS code goes to that number; whoever can enter the code is whoever can reach that channel. Three properties make this durable:

• The operator record already exists. Who holds the number is on file with the operator. You do not need to look it up; when necessary, the competent authorities obtain that mapping from the operator. The box stores the number encrypted and shows it masked in the panel.
• The infrastructure is universal. SMS works on every phone; no app to install, no account to create. It reaches foreign numbers too (and can be routed through a separate provider).
• The provider is replaceable. The box supports several SMS providers and can set up a fallback chain. If one provider has trouble, the next takes over; the guest notices nothing.

By contrast, an externally dependent method has one provider and nothing to put in its place.

The other durable methods

The phone is not the only path. The box's other methods follow the same principle: the channel belongs to the guest or the business, and the dependency is not outside.

Method	Whose channel?	When it fits
SMS code	The guest's number, on file with the operator	Everywhere; the default
Coupon	Issued by the business, which knows the recipient	Hotels, events, places where you prefer not to ask for a phone
E-mail	The guest's address	Corporate visitors, long stays, cases where SMS does not arrive
Registered user	An account the business created	Dormitories, serviced apartments, member-based venues, staff families

All four feed the same record structure: the verification detail, device MAC, assigned internal IP, session start and end. Daily records are chained with SHA-256 digests, time-stamped under RFC 3161 and kept on the box for 2 years. Visited sites are not recorded.

Why there is no social login

That is another example of an external dependency, and it does not count as identification: nobody verifies that a social account belongs to a real person. It also pulls in social profile data, which becomes excess baggage in the business's hands. That is why the box does not offer social login.

How to test for durability

When evaluating a verification method, ask:

• Who outside the business has to say "yes" for the method to work?
• If that party changes the rules tomorrow, can your guests still connect?
• Does the data you collect go beyond what is needed to tie the session to a person?
• Can a foreign guest connect through the same flow?
• Do the records stay in your business, or go to an external service?

Phone verification answers all five comfortably. So do coupons, e-mail and registered users. Methods built on an external identity lookup struggle with the first two.

Practical advice

Turn on the SMS code as the default. Add coupons; they are useful at reception or an event desk. Enable e-mail and registered users at venues that need them. Use device remembering for regulars; your SMS cost drops. They can all live side by side on the box, and the guest picks the one that fits in the portal.

Details of the login methods are in the FAQ and the product options on the products page. For SMS credit packages or using your own provider account, write to us.

This article is for general information and is not legal advice.