Fraud prevention
Approved contacts only. A closed system.
The Ken only accepts calls and messages from contacts that you, the family member, have explicitly approved through the portal. There is no email on the device, no web browser, no app store, and no way for an unknown caller or sender to reach them.
This closed-contact model is our primary defence against telephone fraud, scam calls, and phishing messages. If a person is not on the approved contact list, they cannot make contact. You can add or remove contacts remotely at any time from the family portal or the app.
- No unknown callers - only approved contacts can initiate a video call
- No unsolicited messages - only approved contacts can send messages to the device
- No email - there is no email client on the device, eliminating phishing entirely
- No web browser - no risk of malicious links, pop-ups, or fraudulent websites
- No app store - no risk of accidental downloads, subscriptions, or in-app purchases
- No ads, no pop-ups - the device shows only what matters, nothing designed to distract or sell to the user
- Family-controlled - only authorised family members and carers can modify the approved contact list
How we protect your data on the device itself
If the device is lost or stolen, the data doesn't go with it.
Messages, voicemails, contacts and photos stored on the device are kept in an encrypted partition that can only be unlocked with a passphrase we hold in the cloud. The device fetches that passphrase fresh on every boot. If someone removes the SD card and mounts it on a laptop, all they see is ciphertext.
- Encrypted storage - all user data (messages, contacts, voicemails, photos) sits on a LUKS2 encrypted partition. The passphrase is never on the device at rest; it's only ever in memory between a cloud fetch and mount
- Cloud-delivered unlock key - if the device isn't online, it doesn't unlock. If you report it lost or stolen from the portal, we refuse the unlock request - the data partition stays encrypted even when the device is switched on
- Hardware binding - every cloud request includes the device's unique CPU serial. If someone copies the SD card onto different hardware, our servers detect the mismatch on the next check-in and refuse to talk to it
- Lost & stolen lock - one tap in the family portal locks the device. Lost reports auto-clear after 14 days if you tap "I found it"; stolen reports are permanent and cleared only by our support team
How we protect your data between device and cloud
Nobody sits between your Ken and us.
Everything the device sends to us is pinned to the exact public keys we control. An attacker on your WiFi can't silently impersonate our servers, even with a valid-looking HTTPS certificate from elsewhere.
- Certificate pinning - the device hard-refuses any connection whose certificate chain doesn't match the public keys we pin in the firmware, across three levels (leaf, intermediate, root). Pins rotate on a planned schedule; new pins ship via signed updates before old ones are retired
- Signed software updates - every update bundle is signed with an Ed25519 key we control. The device refuses to install anything without a matching signature, and refuses to trust a swapped verification key - the key's fingerprint is pinned in the app itself, not just a file on disk
- Pinned supply chain - when we build a new device, every downloaded dependency (operating system, Node.js, speech recognition model) is verified against a cryptographic hash. A compromised upstream mirror can't quietly replace something without our build failing
- HTTPS with forward secrecy - every request is encrypted in transit using modern cipher suites; compromising a key later does not let anyone decrypt past conversations
How we protect your account
Who gets in is who you've invited - nobody else.
- Email-verified enrolment - when you buy a Ken, we email an 8-digit setup code to the address used at checkout. Only someone with both the device and access to that email can enrol it. No fleet-wide master password exists
- Per-device encryption keys - no two devices share the same unlock passphrase or API key. Compromising one device never exposes another
- Password hashing - PBKDF2 with 600,000 iterations of SHA-256 (OWASP 2023+ baseline). Legacy accounts upgrade automatically on next login. We never store, log, or email passwords in plaintext
- Multi-factor authentication - TOTP (RFC 6238) required for admin, carer, and HQ roles. Backup codes available for recovery
- Brute-force protection - five failed logins from an IP lock that source out for a cool-off window. Same applies to registration, password reset, and MFA attempts
- Role-based access control - five roles (user, standard, admin, carer, HQ) with explicit per-action permissions. Every API endpoint checks the caller's role server-side; hiding a button in the UI is never the only control
- Second-hand device protection - if a Ken is resold or gifted, the new owner must present a valid setup code from the original customer's email. Old data stays with the original account; the physical device gets a fresh identity
How we protect your data in the cloud
Medical information is always protected.
Medical information, personal identifiers, and anything else sensitive are encrypted at the field level before they're stored - separately from the general database - and accessed only through a documented audit trail.
- AES-GCM field encryption - medical info, care notes, NHS numbers, and dates of birth are encrypted with a key that rotates on a planned schedule
- PII tokenisation - personal identifiers are stored in a separate key-value namespace with its own encryption key; even a full database export doesn't include them in readable form
- Stored in UK / EU - all data sits in Cloudflare's EU data centres, covered by UK GDPR
- Comprehensive audit logging - every access to sensitive data (medical, PII, financial) creates an immutable audit record. Retained even after account deletion, for regulatory defensibility
- Hourly encrypted backups - the database is backed up every hour to cold storage with 7-day retention, encrypted at rest with a separate key
- Session security - HttpOnly, Secure, SameSite=Lax cookies. 20-minute inactivity timeout on the portal. CSRF tokens on every state-changing request
- If you cancel - your data remains accessible for 30 days, recoverable by our support team for a further 60 days, then permanently deleted. A re-subscription at any point in the 90 days restores everything
Vulnerability disclosure
Found a security issue? Tell us.
We welcome reports from security researchers and members of the public. If you believe you have found a vulnerability in The Ken device, the portal, the family app, or our cloud services, please contact us before disclosing it publicly.
How to report
Email [email protected] with a clear description of the issue, the steps to reproduce it, and the potential impact. A machine-readable copy of this policy is published at /.well-known/security.txt.
What we promise
- We will acknowledge your report within one working day
- We will give you a substantive response within five working days
- We will keep you informed as we work on a fix
- We will credit you publicly on this page if you wish, once the issue is resolved
- We will not take legal action against researchers who report in good faith and follow this policy
What we ask
- Give us a reasonable time to fix the issue before disclosing it publicly. Ninety days is our default, less if the issue is already public, more if the fix is genuinely complex
- Do not access, modify, or delete data that does not belong to you
- Do not run automated scanners against the production environment without prior agreement
- Do not test denial of service, social engineering, or physical attacks
- Do not publish or share the issue until we have agreed it is safe to do so
Out of scope
- Issues in third-party services we use (Cloudflare, Resend, Stripe) - please report to the vendor directly
- Reports generated solely by automated scanners with no demonstrated impact
- Missing security headers without a demonstrated exploit
- Self-XSS, clickjacking on pages without sensitive actions, or rate limiting on non-authentication endpoints
Security update commitment
We keep your Ken patched for at least five years.
Every Ken receives security updates over the air. Updates are signed by us, verified by the device, and apply automatically. There is nothing for you to do.
Our commitment. We will provide security updates for every Ken sold from the date of purchase, for a minimum of five years. We expect to provide them for longer; five years is the floor. If we ever change this commitment, we will publish the change here with at least three months' notice for affected devices.
What gets patched. Updates cover the device's operating system, the application running on it, our cloud services, our companion app for iOS and Android, and the family portal. A vulnerability in any layer can affect the others, so all five are kept current together.
How we communicate updates. Critical security fixes are deployed automatically and silently. Material changes (new features, changes to data handling, changes to update cadence) are announced by email to the registered account holder and posted on this page.
This statement satisfies our obligations under the UK Product Security and Telecommunications Infrastructure Act 2022 (PSTI) and the equivalent EU Cyber Resilience Act provisions.
Privacy policy
Your privacy matters.
We collect only what is needed to operate The Ken and keep they connected. All personal and medical data is encrypted, stored in EU data centres, and never shared with advertisers or AI services.
Our full Privacy Policy is available at Privacy Policy.
Terms & conditions
Terms of use.
By using The Ken device and portal, you agree to our terms of service. These cover your subscription, our responsibilities, data handling, and your rights under UK consumer law.
Our full Terms & Conditions are available at Terms & Conditions.