Who Can Control KOKO? Household Accounts and Access Rules

Ask for the actual access model before assigning roles

Start by identifying every way someone could control the proposed KOKO unit: on-device controls, an account, an integration, developer access, or remote support. The public overview does not establish a permission model. Ask Homebot One which control paths exist and who can use each one.

Access design is part of the trial decision because weak or confusing rules can create privacy, safety, and support costs. Evaluate whether the people who need control can receive it without giving every user administrative authority, and ask what limitations apply when the current build cannot enforce separate roles.

Check current KOKO specifications and unknowns →

Prepare focused questions for a KOKO demo →

Separate identity, role, device, and action

Begin with named people rather than one shared household password. An owner may manage the program and billing, a resident may start approved routines, a caregiver may view narrowly defined information, a guest may have no account, a developer may access a test environment, and support personnel may receive temporary diagnostic access. These are planning examples, not claims about KOKO's current interface. Ask Homebot One which distinctions the program can enforce.

Then list the actions that matter: adding users, changing routes, viewing household history, exporting or deleting data, enabling a connected device, installing code, opening a remote session, changing safety settings, and closing the account. A role is meaningful only when its allowed and prohibited actions are visible. Record whether permission applies to the whole home, one person, one room, one routine, or a limited period.

• Who can create, recover, transfer, and close the primary account?
• Which actions require an owner or second approval?
• Can access be limited by routine, data type, location, or time?
• What can a user see about actions taken by other accounts?
• How is temporary support or developer access started and ended?

Evaluate sign-in and recovery as one system

Ask how every control surface authenticates a person or service. NIST SP 800-63B-4 addresses authentication assurance for government systems, while NIST's consumer IoT baseline covers interface access control and authorized configuration. Use them as references for questions about unique credentials, multifactor or phishing-resistant options, session timeouts, device enrollment, and sensitive-action confirmation. They do not establish which controls KOKO provides.

Recovery deserves the same attention as daily sign-in. Determine who can reset credentials, which email address or phone number receives recovery messages, what proof is required, and whether recovery bypasses stronger authentication. Ask what happens when the primary owner loses access, dies, leaves the household, or transfers responsibility. A secure login paired with an easily abused recovery path is not a complete control.

Review KOKO Wi-Fi and connectivity questions →

Use least privilege and visible activity review

Give each person only the permissions required for an agreed routine. A visitor should not need a permanent account to be present in the home. A family member who can start a music or reminder routine may not need access to exports, integrations, or deletion. A developer credential should not automatically expose household data. Ask whether the current product separates these privileges and what safe alternative is available when it does not.

Activity records can help resolve mistakes and suspected misuse, but logs create privacy questions of their own. Ask which account actions are recorded, who can view the record, how long it is retained, and whether it includes sensitive content or only event metadata. A useful review should show enough to answer who changed a setting or opened support access without becoming an unnecessary history of household life.

• Review administrators and integrations on a fixed schedule
• Alert the owner to new users, credential recovery, and sensitive changes
• Time-limit support, contractor, research, and developer access
• Provide a clear way to revoke a lost phone or compromised account
• Record exceptions and restore the normal role after the need ends

Test join, change, and departure before the trial ends

During a controlled demonstration, ask to walk through three harmless scenarios: add a household user, reduce that user's permission, and remove the user. Verify what happens to sessions on other devices, linked services, saved routines, and data the person created. Repeat the exercise for temporary support access if that capability is in scope. Do not use sensitive household content for the test.

Write a small account runbook with the primary owner, backup owner, recovery contact, quarterly review date, and steps for a lost device or departing member. Keep Homebot One's support path with it. The goal is not an elaborate corporate policy; it is a household rule that another responsible person can follow when the usual owner is unavailable.

Set consent rules for children and guests →

Plan long-term support and maintenance →

Review retention and deletion with access rules →

Review the KOKO price and value buyer hub →

Frequently asked questions