DEV Community: 9bot

Shadow IT With Customers Inside: Identity Lifecycle Management for Business WhatsApp Group Portfolios

9bot — Sun, 01 Nov 2026 19:38:52 +0000

The asset that is missing from your IAM

On an employee's last day, offboarding runs like a pipeline: badge disabled, SSO account suspended, laptop collected, SaaS seats reclaimed. The WhatsApp groups that person created with customers, resellers and distributors are not in that pipeline, because they were never provisioned through it.

Ivan Schroll's report calls this a portfolio problem. Sales, support and marketing each open groups informally. A few years later the company holds a set of customer-facing channels that nobody can list completely. Research on shadow IT explains the origin: Abbas and Alghail (2021) found staff using tools such as WhatsApp without IT approval, mainly because the organisation offered no suitable alternative.

Five risks, one root cause

Ownership by creator. The Help Center states the creator cannot be removed and remains admin until they exit. If that account is a personal number, the company depends on the person to leave voluntarily, or must recreate the group from a company number and ask every customer to rejoin.
Privileges that outlive the role. Admin rights are not tied to HR records. Former staff, agencies after contract end and partners who changed jobs may still post as admin to the brand's customers.
Device and account sprawl. Shared accounts on linked devices with no attribution.
Brand impersonation. Customers cannot easily tell an official group from a copy.
No organisational record. Ordinary groups provide no organisation-wide log of admin actions.

There is also a failure mode in the platform's succession logic: if the only admin leaves, WhatsApp picks another member at random, possibly a customer.

Architecture comparison

Aspect	Ordinary group	WhatsApp Business app group	Cloud API Groups API
Maximum size	1,024 members	1,024 members	8 participants
Joining	Added, or invite link	Same	Invite link only, optional approval
Creator removable	No	No	Group belongs to the business number
Admin roles	Unlimited	Unlimited	Managed through the API
Staff on one account	Up to 4 linked devices	Up to 10 with multi-agent plans	API integration
Attribution of staff messages	None documented	Documented for chats, not groups	Business's own systems
Organisation-level record	Manual export	Manual export	Through the integration

No option gives you large customer groups and native organisational control at the same time. That trade-off is the core design decision.

Engineering conclusion: run joiner, mover, leaver on groups

The paper translates standard access governance into proposals, explicitly not tested standards.

Portfolio register. One entry per group or Community: purpose, business owner, creating account and whether it is company-controlled, admin accounts and the person behind each, membership type, settings, records rule and last review date.
Creation rule. New business groups only from company-controlled numbers, registered at creation.
Minimum admin set. At least two company-controlled admins per group, so the random-admin rule never fires. The mechanics are covered in what happens when a WhatsApp group admin leaves.
Joiner, mover, leaver. Grant admin rights on request with a reason, review on role change, revoke in every registered group on the same day as other access. Agency and partner rights end with the contract.
Hygiene. Two-step verification and app lock for every admin account, and periodic review of linked devices.
Customer safeguards. Admin-only messaging in announcement groups, and official numbers and payment methods stated in the description.
Records decision. Each class of group is either a channel of record, exported on schedule, or ephemeral, with disappearing messages and no commitments made there.
Annual reconciliation. Compare the register with the groups company accounts actually belong to.

Automation can execute parts of this at scale, as described in WhatsApp group automation for business, with one constraint: a tool acts with the permissions of the connected account and cannot remove a group's creator.

Source: Ivan Schroll (2026), Governance and Operational Security of Business WhatsApp Group Portfolios: Administrator Lifecycle, Employee Offboarding, Brand Impersonation and Recordkeeping. DOI 10.17605/OSF.IO/G6HF9

Author: Ivan Schroll (ORCID 0009-0007-0680-5570)

Your Customer Group Is a Database: LGPD and GDPR Engineering Notes for Business WhatsApp Groups

9bot — Sun, 01 Nov 2026 19:38:39 +0000

An unregistered data store

Ask a data protection team for the list of systems that process customer phone numbers and you will get the CRM, the ticketing tool and the email platform. You will rarely get the WhatsApp groups that sales, support and partner teams created on their own phones. Yet each of those groups is a replicated data store: every member's device keeps a copy of the conversation and of the member list, with no central administration and no deletion API.

Ivan Schroll's report analyses these groups under Brazil's LGPD and the EU GDPR. Its starting point is scope. The LGPD excludes processing by a natural person for exclusively private, non-economic purposes, and the GDPR excludes purely personal or household activity. Neither covers a legal entity acting for its business. A customer community, a reseller group or a support group is in scope, even when the number behind it is an employee's phone.

Role assignment

The organisation that decides to create the group, who joins and what it is for is, as a rule, the controller.
WhatsApp's data processing terms for WhatsApp Business apply to the services described in the Business Terms. For groups created from ordinary accounts, the organisation cannot assume a processor agreement exists.
When a manufacturer and its distributors jointly decide a group's purpose, the EDPB criteria for joint controllership may be met. The paper recommends a written split of who answers member requests and who manages admins.

Lawful basis by use case

Use of the group	Basis to assess	Note
Post-sale support for customers who asked to join	Contract or pre-contractual steps	Limited to what support requires
Optional customer or brand community	Consent or legitimate interest	Legitimate interest needs necessity, transparency and balancing (LGPD art. 10)
Reseller or partner groups	Contract or legitimate interest	Partner contact persons are data subjects
Internal team groups	Employment, legitimate interest	Business app terms say it is not intended for intra-company use
Marketing and promotions	Consent is the common route	Platform opt-in rules also apply

Lateral exposure as a design flaw

The defining property of a group is that members see one another. A customer community of several hundred people is therefore a list of several hundred customer numbers readable by every member, including competitors, former staff still inside and anyone who joined through a leaked link. LGPD principles of necessity, security and prevention (art. 6), the security duty in art. 46, and GDPR data minimisation, integrity and confidentiality (art. 5) with privacy by design (art. 25) all point the same way.

The Business Messaging Policy also says a business may not share information from one customer chat with another customer. Individual cases raised in front of other customers sit badly with that rule.

Retention in a distributed system

Deletion duties (LGPD arts. 15 and 16, GDPR storage limitation) are hard when copies live on member devices. What the organisation can do: enable disappearing messages and restrict changes to admins, remove members whose purpose has ended, and decide whether exports are needed. An export is a text file that cannot be re-imported, and it becomes a new record with its own retention rule.

Engineering conclusion: access control is a compliance control

Inventory first. Register each group with purpose, legal basis, data involved, admins and retention. The paper sees little risk in exotic legal questions and a lot in missing basic documentation.
Minimise visibility. If members do not need to see each other, use announcement-only groups, Communities with an announcement group, or one-to-one conversations.
Control admin access. The creator cannot be removed, admin rights attach to accounts, and ordinary groups have no organisation-wide admin log. You have to build that record yourself.
Include your tools. Automation processes data too, so it belongs in the record of processing. The page on WhatsApp group data collection and privacy compliance lists what an admin can collect and on what basis.
Assign accountability. Admins are people with duties, as discussed in this piece on WhatsApp group admin legal responsibility.

The author notes the paper is not legal advice.

Source: Ivan Schroll (2026), Personal Data Protection in Business-Operated WhatsApp Groups: Controller Duties, Lawful Basis, Phone-Number Exposure, Retention and Incident Response under the LGPD and the GDPR. DOI 10.17605/OSF.IO/ZG9U7

Author: Ivan Schroll (ORCID 0009-0007-0680-5570)

Groups as an Attack Surface: A Control Matrix for Scam Links in WhatsApp Communities

9bot — Sun, 01 Nov 2026 19:38:12 +0000

Why fraud teams should care about group chats

Security teams usually model fraud at the payment layer or the email gateway. Messaging groups sit outside both. A large WhatsApp group is a broadcast channel with no content filtering by default, a shared directory of every member's phone number and an implicit trust signal: if a message appears inside a group you joined, it borrows the group's credibility.

Ivan Schroll's report reviews scam families that official sources associate with messaging groups and maps them to controls an administrator can actually operate. It covers employment and task scams, investment fraud, impersonation and fake offers, with attention to Pix payments in Brazil.

The scale is not hypothetical. In August 2025 Meta reported banning more than 6.8 million accounts linked to scam centres in the first half of that year. The WhatsApp Help Center acknowledges that a scammer may message you, call you or add you to a group.

Cross-platform kill chain

The most instructive case described by Meta looks like a distributed workflow:

Initial contact by SMS with a link to a WhatsApp conversation.
Migration to Telegram.
"Tasks" on TikTok to simulate paid work.
A deposit request to a cryptocurrency account.

Meta notes that scammers move victims across platforms so that no single service observes the full scheme. For a defender, that means no single log source contains the incident. The group admin sees only the entry point.

The FBI's 2024 alert on task scams describes the same economics: confusing pay, a dashboard showing earnings that can never be withdrawn and, eventually, a demand for crypto payment to unlock more work.

Control matrix

Scam pattern	Documented feature	Capability and limit
Phishing, fake shop or task links	Link moderation with an allow list and automatic removal	Removes links outside the list; cannot judge a link that is allowed
Repeated posting of one offer	Anti-spam and anti-flood	Caps volume; one well-crafted message may pass
Recurring offenders	Banned words, strikes, punishment ladder	Consistent consequences; spelling variants evade word lists
Scam accounts joining via shared link	Member approval with filters, daily limits, history	Slows entry and leaves a record; cannot verify intent
Incident awareness	Moderation history and community health analytics	Shows what was done; blind to private chats between members
"Is this offer real?" questions	Automatic replies and custom commands	Returns a standard safety notice; not fact-checking

Read the right column carefully. Every control has a documented failure mode, and the paper does not oversell any of them.

Indicators to encode

Unexpected contact or being added without request.
An offer that is too good.
A request to pay before earning.
Urgency.
A link that moves the conversation somewhere else.

These map well to rules: link policies catch the last item, approval filters reduce the second, and pinned notices handle the human side.

Engineering conclusion: default deny at the group boundary

The admin cannot inspect private chats or other platforms, so the design goal is to make the group a poor first hop.

Default deny for links. Maintain an allow list of domains the community actually needs and remove everything else automatically. The guide on how to filter links and files in WhatsApp groups walks through allow lists and file rules.
Gate entry. Require approval for join requests, with filters and daily limits, so a burst of fresh accounts cannot arrive through one leaked link.
Make enforcement deterministic. Strikes and a punishment ladder turn moderation into policy instead of mood. Operational shortcuts such as admin commands for WhatsApp groups keep response time low.
Publish an invariant. State in the description that admins never ask for payment or codes in private. That is a cheap implementation of Meta's "pause, question, verify" advice.
Keep records. Moderation history is your only audit trail inside the group.

None of this stops a determined fraudster who moves the victim into private chat. It does remove the group as an amplifier, which is the part an administrator controls.

Source: Ivan Schroll (2026), Scams and Malicious Links in WhatsApp Groups: Employment, Investment and Impersonation Fraud, Pix Payments in Brazil and Administrator-Level Controls. DOI 10.17605/OSF.IO/CYP2G

Author: Ivan Schroll (ORCID 0009-0007-0680-5570)

Invite Links Are Bearer Tokens: Access Control and Phone-Number Exposure in Large WhatsApp Groups

9bot — Sun, 01 Nov 2026 19:36:47 +0000

A credential nobody rotates

A WhatsApp invite link behaves like a bearer token. Whoever holds it can join, and the Help Center confirms that anyone with the link can also forward it. There is no expiry by default, no scope and no binding to an identity. Once the token is published on a website, a social network or a forum, the group's access control list becomes public.

Joining has a side effect engineers should treat as a data disclosure: members can see each other's phone numbers. So a leaked link is not only an unwanted entry problem. It is an enumeration path for a list of personal identifiers.

Ivan Schroll's report argues that access control is the main privacy instrument available at group level. The admin cannot change the fact that members see numbers. The admin can decide who reaches that list.

What the measurements show

Garimella and Tyson (2018) showed that public WhatsApp groups can be discovered through links scattered across the web and joined for data collection.
Hoseini and colleagues (2020) collected 351,000 unique group URLs for WhatsApp, Telegram and Discord posted on Twitter in 38 days. In the WhatsApp groups they joined, the numbers of 54,984 users were visible to them as members.
The same study found that 27% of WhatsApp group links stopped working within the 38 days, which suggests admins revoke or reset links over time, often after exposure.
Gegenhuber and colleagues (2026) showed that WhatsApp numbers could be enumerated at large scale through contact discovery before the platform applied remediation, which is why rate limits matter.

Control plane

Control	Applied by	Effect
Approve new members	Admin	Link join requests wait for approval
Restrict who adds members and shares the link	Admin	Narrows who can distribute the token
Reset invite link	Admin	The old link stops working and cannot be restored
Keep links off public pages	Admin	Reduces discoverability
Avoid @mentions in announcement groups	Admin	Avoids exposing numbers to the whole community
Who can add me to groups	User	Limits unsolicited additions
Usernames and username key	Platform and user	Contact without sharing a number, rolling out gradually
Rate limits on contact discovery	Platform	Reduces enumeration at scale

Tooling layer and its limits

Consistent screening. Approval with filters, daily limits and history. Filters only see the data available at entry and cannot verify intent.
Burst protection. Daily approval caps and anti-flood rules slow mass entry, but a single targeted account still gets through.
Membership hygiene. Removing inactive members, with prior notice, reduces passive observers.
Time-boxed access. Fixed-period membership fits courses, events and paid communities.
Audit. Approval and moderation history support accountability, and the records themselves contain personal data.

Engineering conclusion: treat the link like a secret

Apply the same hygiene you use for API keys.

Do not publish it. WhatsApp's own community guidance says never to post invite links on public web pages.
Gate redemption. Enable approval so possession of the link is not sufficient. When requests are frequent, rules can auto-approve WhatsApp group members that match filters, under a daily limit, with a record of every decision.
Rotate on leak. Reset the link when it appears somewhere it should not. This explainer on the WhatsApp group invite link covers how links are created, shared and revoked.
Restrict distribution rights. Only admins should add members or share the link in large groups.
Minimise the directory. If members do not need to talk, an announcement format exposes less.

Welcome messages that state the rules inform new members, but they do not prevent link leakage on their own. The boundary is the approval step.

Source: Ivan Schroll (2026), Access Control and Member Privacy in Large WhatsApp Groups: Invite-Link Exposure, Phone-Number Disclosure and Unwanted Entry. DOI 10.17605/OSF.IO/WFDQ3

Author: Ivan Schroll (ORCID 0009-0007-0680-5570)

Admin Accounts as Privileged Identities: Threat Modelling WhatsApp Group Takeover

9bot — Sun, 01 Nov 2026 19:34:30 +0000

The identity problem behind a chat group

Treat a WhatsApp group the way you would treat any shared resource in your infrastructure. It has an access control list (members), a set of privileged principals (admins), a configuration surface (who can edit info, add people, share the invite link, approve joins) and no central identity provider. Each admin is a phone number, and authentication to that number is bound to a one-time registration code delivered over SMS or voice.

That design means the security of a group with hundreds of members is reduced to the weakest admin endpoint. If one admin hands over a six-digit code to a caller pretending to be a bank or a shop, the attacker does not exploit a vulnerability. They complete a legitimate registration flow on hardware they control, and the platform behaves exactly as specified.

The report by Ivan Schroll maps this chain using institutional sources from Brazil (FEBRABAN, the civil police of São Paulo and Mato Grosso, MPDFT) and the WhatsApp Help Center. Below is the part most useful to engineers.

Attack chain, step by step

Target selection. The attacker obtains a name and phone number. Group membership itself leaks numbers to every participant.
Code trigger. A registration for the victim's number is started on an attacker device, so the real owner receives a code.
Pretext. The attacker calls or messages, posing as customer service, and asks for "a code" framed as a protocol or confirmation number.
Re-registration. The account moves to the attacker's device. Past messages are not readable, because they are end-to-end encrypted and stored locally, but group membership is inherited immediately.

A variant worth modelling: the attacker enables two-step verification with a PIN the victim does not know. The Help Center states that a user without the PIN must wait 7 days before trying again. That is a week of attacker persistence on a privileged account.

Secondary surfaces

Linked devices. A primary phone can link up to four companion devices, and companion phones are logged out after more than 14 days without use of the primary. Linked sessions are a second place to audit after any suspected compromise.
SIM swap. Lee, Kaiser, Mayer and Narayanan (2020) showed that five US prepaid carriers used authentication challenges attackers could subvert. SMS delivery of codes inherits carrier support weaknesses.

Blast radius mapped to controls

Damage path after takeover	Documented control	Residual limit
Phishing or payment links posted by the hijacked admin	Allow-list link filtering that deletes other URLs	Payment requests without links still pass
Flooding the group	Anti-spam and anti-flood thresholds, strikes	A careful attacker stays under the threshold
Accomplice accounts joining	Member approval with filters, daily limits and history	Native admin rights can still add members
No forensic trail	Moderation history and action records	Only covers actions taken through the tool
Sensitive actions requested via an AI assistant	MCP access with verified identity, scoped access, confirmation and audit history	Only covers the MCP interface

The paper is explicit that these consequences follow from documented features, not from measured incidents. There are no official figures on how often admin accounts are hijacked.

Engineering conclusion: least privilege for group admins

The mitigation pattern is the same one you apply to cloud consoles.

Harden every privileged identity. Never share the code, enable two-step verification, add a recovery email or passkey where available, and review linked devices on a schedule.
Avoid a single point of failure. Keep more than one admin, but not everyone. One admin means no one can remove a cloned number; ten admins means ten phishing targets.
Lock the configuration plane. Restrict editing of group settings to admins, require approval for new members and reset the invite link after any incident, since a reset permanently invalidates the previous URL.
Separate human access from admin rights. Per-user dashboard access lets a team moderate without each person holding native admin rights. The 9bot documentation describes how access per user, history and approval rules are configured.
Plan the role lifecycle. Granting, reviewing and revoking admin status should be a routine task, as covered in this guide on how to add, change or remove a WhatsApp group admin.

Any bot or automation connected to the group runs with the permissions of its account, so that number needs the same protection as a human admin. Tools act after the takeover, not before it. The weak link remains the person persuaded to read a code aloud.

Source: Ivan Schroll (2026), Account Takeover of WhatsApp Group Administrators: Verification-Code Hijacking, Linked Devices and Layered Mitigations. DOI 10.17605/OSF.IO/HZUN5

Author: Ivan Schroll (ORCID 0009-0007-0680-5570)