WhatsApp Web Logout in India: Historical Direction and Current Checks

A DoT-hosted PIB release dated 1 December 2025 describes directions issued on 28 November under the Telecom Cyber Security Rules. It reports SIM binding, periodic web-instance logout no later than six hours with re-linking, and announced implementation/reporting periods of 90/120 days. It attributes the measures to preventing misuse of telecom identifiers and cyberfraud.

That PDF is a press release, not the signed direction or a current consolidated instrument. Its description of the policy is historical context. It does not by itself establish current deadlines, amendments, exceptions, the precise desktop-client scope or the behavior of a particular WhatsApp account.

The original article labelled 27 February 2026 final, said no exceptions existed and asserted implementation across web and desktop apps. Those present-tense conclusions are held. This check did not obtain the underlying direction, current amendment/extension set or authoritative account implementation notice. Absence of that evidence does not prove repeal, universal enforcement or continued applicability unchanged.

Do not calculate today’s deadline by adding days to an old press release, infer a legal exemption from product architecture, or promote an observed logout into a legal conclusion. Obtain the relevant instrument and current provider guidance, then have the responsible legal/operational owner assess the scope for your account and workflow.

Use this historical explanation to frame the question. Obtain current authoritative support before relying on it for an operational deadline; this article is not an enforcement notice.

Use a source-backed chronology with separate columns for what was reported and what remains to verify. The old approaching-deadline labels are no longer useful as current instructions. A build or documentation check date is not an amendment date and does not change the article’s original publication record.

If an authorized web session logs out, record the client/app version, time, notice and permitted recent device/account changes. Distinguish a logout from a network failure, expired login, revoked device, app update or local browser problem. A single incident does not establish a fixed timer or a country-wide cause.

Investigation map

Observe the interruption before naming its cause

A dated direction does not prove why a particular browser-linked session disconnected today.

01

Observe

Record the connection, device and client state at the time of interruption.

02

Separate

Keep historical announcements apart from current account evidence.

03

Recover

Give staff a safe route to resume work without a guessed timer.

Follow the genuine app’s supported re-link/recovery process with the account owner. Do not share verification codes or authorize an unexpected device to keep a session alive. Keep customer drafts and case references in an approved work system where appropriate; avoid copying sensitive chat content into a public note or unapproved document.

The earlier countdown example promised what happens to active calls, unsent text and chat history at exactly six hours. Those outcomes need client/account evidence. Verify continuity and synchronization after recovery instead of assuming every draft or message survived. Do not repeatedly re-link devices without understanding who is authorized.

Map who depends on web/desktop access, which conversations are time-sensitive and how a person takes over during a session or network interruption. Document an approved recovery contact and a backup channel. A support handoff should preserve case ownership so two operators do not issue conflicting replies.

A fixed six-hour break schedule and promised five-minute recovery would hide the unresolved evidence. Use the actual approved operating conditions and observed disruption to plan coverage. Measure lost handling time separately from waiting time and avoid attributing every delay to a regulation.

A browser-linked workflow depends on the supported session and client behavior. A supported Cloud API integration uses its API credentials and provider services rather than a browser QR session as its sending path. That architectural distinction is not proof of a regulatory exemption, unlimited access, uninterrupted delivery or a particular SLA.

API operations still depend on valid credentials, permissions, account/template/recipient conditions, supported integration, connectivity and provider availability. Team interfaces and automation are separate implementation choices; they are not automatically built into every API setup. An accepted send does not guarantee delivery or billing resolution.

If a workflow relies on an unofficial browser bridge, assess the supported replacement and safe number migration path. Confirm standard versus hybrid eligibility, history/device scope and recovery before changing a working number. Do not delete the app or re-register simply to avoid a reported session issue.

Start with evidence and task ownership before buying a replacement service. Confirm the intended message types and recipient permissions, the actual integration path, account eligibility and current commercial terms. The historical announcement does not establish that a new system will be ready by a fixed date.

Use synthetic records to rehearse interruption, duplicate handoff, a failed reconnection and an unavailable API dependency. An approved pilot should measure correct resolutions, failures, handling time and recovery—not just whether a page or login worked. Local rehearsal cannot prove provider implementation or legal compliance.