Eiliko Robot Security: How to Protect Chats and Child Data
Learn how to reduce Eiliko robot privacy risks, disconnect the device, secure your home network, review linked accounts, and assess whether a security fix is trustworthy.
On this page
If an Eiliko companion robot has been connected to your home Wi-Fi, the privacy risk may extend beyond what someone says to the toy. A security investigation published by The Verge on October 15, 2026, reported that researcher Sammy Azdoufal could access conversations and user profiles associated with Energize Lab's connected robots and alter how a robot responded. The findings raise a practical question for owners: what can you do when a connected device's cloud service may be exposed, but a verified fix is not yet established? This guide explains how to reduce exposure, protect your home network, and assess any future security update without assuming that a software patch has resolved every issue.
Understand what the Eiliko security investigation actually found
Eiliko is a Wi-Fi-connected companion robot made by Energize Lab. It uses cloud services to support conversational features, which means information exchanged with the toy may leave the home network and be processed or stored on remote servers. That arrangement can make the product more capable, but it also creates security dependencies that owners cannot inspect or repair themselves. If the service does not enforce proper access controls, information intended for one household could become accessible to someone else.
In its investigation, The Verge worked with Azdoufal to examine the infrastructure behind a robot purchased for testing. The reporting described access to approximately 13 million conversation records and data associated with 68,000 devices, including profiles belonging to children. The figures describe what the researcher reported observing; they should not be interpreted as proof that every record was stolen by a criminal or that every device was compromised. The investigation also reported that the researcher could change the robot's stored information and influence its responses remotely.
The central issue is not simply whether the toy has a strong password. Security weaknesses in a cloud application can expose data even when a customer uses a unique password and has not installed malware. Similarly, changing a household Wi-Fi password will not repair an access-control flaw on a manufacturer's server. Owners therefore need to reduce the device's connectivity while checking whether the manufacturer has established an independently verifiable remediation process.
Disconnect the robot before investigating further
If you own an Eiliko and are concerned about the reported findings, disconnect it from Wi-Fi rather than continuing normal conversations while you investigate. If the device cannot be reliably disconnected through its controls, power it off and keep it offline until you have reliable information about the security status. This is a precaution based on the reported exposure, not a claim that every unit is currently under active attack. Do not connect it to another household network simply to test whether it still works.
Next, identify the associated application, account, and any other devices used to control the robot. Avoid sharing additional personal information with the toy while its data handling remains uncertain. If you need to document the product for a support request, record its model, firmware version, application version, and purchase details without posting serial numbers, account identifiers, or children's information publicly. These details can help you determine whether a later security notice applies to your specific configuration.
Keep in mind that disconnecting a robot prevents further communication over that connection, but it cannot retrieve conversations already sent to a remote server. It also does not establish whether the manufacturer has deleted existing records or whether unauthorized parties previously accessed them. Those questions require evidence from the service operator, not merely a change to settings in your home.
Check for a verified security fix before reconnecting
Look for a security announcement from Energize Lab that identifies the affected products, describes the corrected weaknesses, and explains how owners receive the fix. A general statement that an application or firmware release is available is not enough to establish that the reported cloud-side problems have been addressed. Firmware is the software that runs on the device itself, while the cloud service is the remote infrastructure that supports its connected features; updating one does not necessarily repair the other.
When a vendor announces an update, check the exact model and version numbers against the affected-product list. Look for a release date, an explanation of the changes, and instructions for installing the update safely. If the vendor offers a way to verify that the cloud service now requires proper authentication and restricts each account to its authorized data, that evidence is more meaningful than a vague assurance that security has been improved. Independent confirmation from a researcher or credible security assessment would provide additional confidence.
As of the reporting examined for this guide, I could not establish a comprehensive, independently verified fix for all the reported Eiliko findings. That uncertainty is a reason to remain cautious, not proof that no individual weakness has been fixed. Until the relevant remediation is documented, avoid reconnecting the device merely because an application update appears in an app store.
Secure the home network without relying on it to fix the cloud
While the robot remains offline, review the router's connected-device list and identify the robot by its device name or network address where possible. If it is still connected, block its access or remove it from the network using your router's management interface. Router interfaces differ by manufacturer, so use the instructions for your specific model rather than applying unfamiliar firewall commands. Confirm that the device no longer appears as an active client, while remembering that a missing entry does not prove that data previously stored in the cloud has been removed.
If you later decide to use the toy again after a verified fix, place it on a guest network or a separate Internet of Things (IoT) network when your router supports that feature. IoT describes internet-connected devices such as cameras, speakers, sensors, and smart toys. Network separation limits the device's direct access to computers, phones, and shared storage on your main network. Disable guest access to local devices where possible, and avoid granting the toy access to network shares or administrative interfaces.
Network isolation is a supplementary control rather than a complete solution. A device placed on a separate network may still communicate with its manufacturer's cloud service and transmit information to it. If that service continues to expose records or permits unauthorized changes, the separation of home devices will not repair the underlying vulnerability.
Review accounts and protect information already shared
Check the account associated with the robot for unfamiliar logins, unexpected changes, or connected sessions you do not recognize. If the service supports password changes, use a unique password that you do not reuse on email, shopping, or social media accounts. Enable multifactor authentication if it is available; this requires an additional verification step beyond the password. These steps reduce the risk of account takeover, although they do not correct server-side authorization weaknesses that might expose information without logging in as the victim.
Review any linked accounts and revoke access that is no longer needed. If the robot's application uses a third-party sign-in service, review the connected application permissions through that provider's account-security settings. Keep records of any unexpected activity and contact the manufacturer through a verified support channel. Do not send passwords, authentication codes, or full conversation transcripts as part of a support request unless there is a clearly justified and secure process for handling that information.
Families should also consider what the toy may already have learned about a child. Conversations can reveal names, routines, relationships, worries, school details, and other personal information even when a child never enters a password. Explain in age-appropriate language that connected toys are not the same as private diaries. Until the product's data practices are adequately explained and its security is verified, avoid sharing sensitive family information with it.
Ask the manufacturer specific questions about stored data
A useful support request should ask for concrete answers rather than a general promise of safety. Ask whether the reported access-control weaknesses have been fixed in the cloud service, whether affected device and application versions require updates, and how the company verifies that each user can access only authorized records. Also ask whether existing conversation histories, photographs, audio files, and child profiles remain stored, how long they are retained, and what process is available to request deletion.
Request clarification about whether any unauthorized access has been confirmed and whether the company has rotated potentially exposed credentials or other secrets. Credential rotation means replacing credentials that may have been disclosed so that an old value can no longer be used. If a security incident affected the service, the vendor should explain what customers need to do and whether any account-specific action is required. A lack of public confirmation should be treated as an unresolved question, not as proof of either a breach or a clean bill of health.
Keep the response and the version information supplied by the manufacturer. If the answers do not identify the affected components, the remediation steps, and a way to verify the result, continue treating the device as untrusted. Do not attempt to probe the company's production servers or retrieve other customers' information yourself; security testing should be authorized and confined to systems you own or have permission to assess.
Know what a safe return to service should look like
Before reconnecting the robot, look for evidence that the cloud service has corrected the reported access controls, that affected software versions are identified, and that the manufacturer has explained how updates are delivered. Verify the update through the official application or documented vendor process, and check the resulting version against the published security notice. If the vendor cannot explain what changed or the relevant weaknesses remain unresolved, leaving the device disconnected is the more cautious choice.
After a verified remediation, reconnecting the toy on an isolated network can reduce the potential impact of future device-level problems. Monitor its network activity through your router if that feature is available, review account activity, and avoid granting unnecessary permissions. These precautions do not guarantee that a cloud service is secure, but they reduce the amount of trust placed in a single consumer device.
For parents, the decision is ultimately about whether the product's conversational benefits justify the information it collects and the uncertainty surrounding its handling. If the manufacturer cannot provide credible evidence of remediation and clear answers about stored children's data, keep the robot offline and consider requesting deletion of the associated records. A connected toy should earn its place back in the home through verifiable security improvements, not merely through reassuring language.
Share this post
Written by


