Free Wi-Fi is not unaccountable Wi-Fi
Offering Wi-Fi to guests, customers or the public is good hospitality and good business — but in India, as in most countries, it comes with responsibilities. The provider of an internet connection is expected to know, in broad terms, who used it and when, so that misuse can be traced if the authorities lawfully require it. “Free” Wi-Fi does not mean anonymous, unlogged Wi-Fi. The good news is that meeting these expectations need not slow the guest down at all.
This guide explains, in practical terms, what a compliant public or guest Wi-Fi deployment captures — identification, consent and logs — and how a well-designed captive portal handles it invisibly. It is written for hotels, cafés, hospitals, retailers and public-space operators who want to offer Wi-Fi confidently and lawfully. It is general guidance, not legal advice; confirm the specific obligations for your operation with a qualified professional.
What the law is really asking for
Strip away the detail and the expectation comes down to traceability with consent. A provider should be able to establish that a particular session belonged to an identifiable user, that the user agreed to acceptable terms, and that a record exists which can be produced on lawful request. The exact wording of obligations has evolved and varies by the framework that applies to a given operator, but the underlying principle has been remarkably stable.
Crucially, this is about identification and record-keeping, not surveillance. You are not expected to inspect content; you are expected to know which verified user held a session at a given time and to keep that record safe. Designing to that principle keeps you on solid ground even as the precise rules are refined over time.
- Identify the user — commonly via OTP to a mobile number
- Consent — record agreement to acceptable-use terms
- Log — retain session, time and device securely for a defined period
- Isolate — keep guest traffic off operational systems
Identification: establishing who connected
The first pillar is identifying the user. The most common low-friction method is an OTP — the guest enters a mobile number, receives a one-time password, and enters it to gain access. This ties the session to a verified contact and takes seconds. Alternatives exist: a hotel can authenticate against the PMS using room and name, an enterprise can use sponsored access, and some operators use social or email verification.
The method should match the venue. A café might use OTP; a hotel ties access to the stay; a corporate guest network might require a sponsor. What matters is that each session is linked to an identity that could be traced if lawfully required, rather than handed out anonymously to anyone in range.
Consent: recording agreement to terms
The second pillar is consent. Before reaching the internet, the user should see and accept an acceptable-use policy and any privacy notice — and that acceptance should be recorded. This protects the provider (the user agreed to the terms) and informs the user (they know the network is logged and what is and is not permitted). The captive portal is the natural place to present this, as a checkbox or an explicit accept step.
Good portals make consent clear without making it a chore: a concise, readable policy and a single acceptance, branded to the venue. Burying consent or making it confusing helps no one; presenting it cleanly satisfies the requirement and sets honest expectations with the guest.
Logging: what to keep and for how long
The third pillar is the log. At minimum, a compliant record ties a verified identity to a session: which user, which device (by MAC and assigned IP), start and end times. These records must be retained securely for a defined period and be producible on lawful request. Retention windows have generally been framed in months; the safe practice is to choose a clear, documented period comfortably on the generous side and protect the data well.
Security of the logs themselves matters as much as keeping them. They contain personal data and should be stored with appropriate access controls and protection, not left in an open file. The aim is to be able to answer a lawful request accurately while safeguarding the very information you are required to keep.
Isolation: the security half of compliance
Compliance is not only about logging; it is also about keeping guest traffic where it belongs. Guests should land on an isolated network with no path to your operational systems — point-of-sale, property management, building controls, staff devices. This is achieved with VLAN segmentation, and it protects both you and the guest: a compromised guest device cannot reach sensitive systems, and your operations cannot be disrupted by guest activity.
Isolation also limits what your logs ever need to concern: guests on a contained segment simply reach the internet, cleanly separated from everything that matters. Designing identification, consent, logging and isolation together is what turns “we offer Wi-Fi” into “we offer Wi-Fi responsibly”.
The PM-WANI model for public Wi-Fi
For genuinely public Wi-Fi — not just guests of a single venue — India’s PM-WANI framework provides a structured, government-backed model with defined roles for public data offices, aggregators and app providers, and a built-in approach to authentication and accountability. For anyone building a public Wi-Fi business rather than a guest amenity, it is the natural route, and we cover it fully in our guide to building a PM-WANI public Wi-Fi business and the step-by-step PDO guide.
PM-WANI bakes much of the compliance thinking into its design, which is part of its appeal: rather than assembling identification and accountability yourself, you operate within a framework built for it. For a venue simply offering guest Wi-Fi, a captive portal is the right tool; for public Wi-Fi at scale, PM-WANI is worth serious consideration.
Keeping it frictionless
The fear that compliance means a slow, ugly login is misplaced. A well-built portal verifies a user, captures consent and starts logging in the time it takes to enter an OTP — and on return visits it can recognise the device and let the guest straight through. The legal machinery runs invisibly behind a clean, branded page. Friction comes from bad implementation, not from compliance itself.
This is exactly the experience guests expect: tap to connect, a quick verify, and they are online. Done well, they never perceive the identification, consent and logging happening underneath — which is the mark of a portal that serves both the guest and the law.
Returning visitors and a frictionless experience
Compliance and convenience are not opposites. A well-built portal can recognise a returning device and grant access without forcing the full verification each time, within the bounds the venue sets, so a regular at a café or a returning hotel guest taps once and is online. The legal record still exists; the user simply does not have to repeat the ceremony. This is the difference between a portal people resent and one they barely notice.
The design goal is a login that takes seconds on first use and is near-invisible thereafter, while quietly maintaining identification, consent and logging underneath. When the experience is smooth, guests use the Wi-Fi more, the venue benefits, and compliance is satisfied without anyone feeling policed — the outcome every operator actually wants.
Branding the portal as a venue asset
The captive portal is a screen every visitor sees, which makes it a genuine asset rather than mere plumbing. A branded portal carries the venue’s identity, can promote services or offers, and sets the tone for the visit — a hotel can showcase its restaurant, a retailer a promotion, a city its services. The same page that captures consent and starts logging can do real marketing and communication work.
This dual role is part of why a flexible, well-designed portal is worth more than a bare login. It turns a legal obligation into a branded touchpoint, and on a managed platform the same portal design can be pushed consistently across every site, so a chain presents one identity everywhere while each location stays individually compliant.
Common compliance mistakes
A handful of mistakes recur in public Wi-Fi deployments. The first is offering truly open access with no identification at all — convenient, but it leaves the provider unable to answer a lawful request. The second is capturing identity but storing logs insecurely or for an undefined period. The third is failing to isolate guest traffic, so the guest network can reach operational systems. The fourth is treating consent as an afterthought rather than a clear, recorded step.
Each has a straightforward fix: verify users, retain logs securely for a defined window, isolate guest traffic on its own VLAN, and present consent clearly. Designed in from the start, these are settings rather than projects — and they keep an operator on solid ground as the specific rules evolve.
- Offering truly open access with no identification
- Storing logs insecurely or for an undefined period
- Failing to isolate guest traffic from operational systems
- Treating consent as an afterthought rather than a recorded step
Building compliance into the platform
The most reliable way to stay compliant is to make compliance a property of the platform rather than a manual discipline. When identification, consent capture, secure log retention and guest isolation are built into the system and applied automatically to every site, there is no opportunity to forget a step at one location. Central management also means a change in approach can be rolled out everywhere at once as expectations evolve.
Immunity delivers this through Net Cloud and the captive portal solution: authentication, consent, logging and VLAN isolation configured once and enforced consistently across a single venue or a whole estate. Compliance becomes the default behaviour of the network, not a checklist someone has to remember at each new site.
Building it on Immunity
Immunity’s captive portal, delivered through Net Cloud, brings these pieces together: flexible authentication including OTP and PMS integration, recorded consent on a branded page, secure session logging with defined retention, and VLAN isolation of guest traffic. It works across a single venue or a fleet of sites managed centrally, with the analytics and visibility to run guest Wi-Fi well.
The result is public or guest Wi-Fi you can offer with confidence — a clean experience for the visitor and a defensible, documented posture for you. If you are deploying guest or public Wi-Fi and want it to be both delightful and compliant, our team will design the portal, logging and isolation to fit your venue and the obligations that apply to it.