Security

How KardoVision protects your sites, your video and your account — as built today.

Draft — not yet reviewed by counsel. This text describes KardoVision as it works today. Anything in [brackets] is a placeholder to be settled before this page is final.

The shape of it

The cloud manages the organisation; the KardoHub runs and understands the site; every Kardo device can run itself. Nothing critical depends on the tier above it: recording, door access and local AI carry on through an internet outage, a hub failure or a screen crash. Video is recorded on the KardoHub’s own disk at your site and leaves it only as far as each camera’s privacy mode allows.

Devices dial out; nothing dials in

• A KardoHub, a Kardo camera or a terminal opens one outbound, encrypted connection to the cloud. No port is opened on your router, and the phone app and the web console never use a device’s local address.
• Live view, playback, intercom video and phone audio are relayed through that connection with short-lived tickets; the cloud stores none of it.
• Each device holds its own certificate. New firmware makes its key on the device and asks the cloud for a certificate; the key never leaves the device (built; being proven in production).
• Only genuine devices are described as genuine: every unit Kardo makes is registered with a secret written into the hardware at manufacture, of which only a hash is kept. A device reported stolen can be blocked and will never be claimed again. Claim codes expire after a day; device tokens can be revoked; a device released from an account is locked out on its next request.
• Commands to a device are checked by the device: for it, not expired, not a repeat, in a format it understands — and a screen never says “Done” until the device says so.
• Door terminals get a certificate from their KardoHub and talk to it only over an encrypted, mutually checked link (built; older readers show “Insecure link” until replaced).

Signed firmware, apps and models

• Hub, camera, terminal and screen updates are signed by Kardo with a key that is not in the repository. The device checks the signature before installing and rolls back by itself if the new version does not prove healthy (three minutes on a two-slot hub, fifteen on an installed one).
• AI model packages are signed with a separate key. The signing tool refuses a model that has no recorded provenance (code, weights, data, conversion), and the licence of every model and package is audited before release — see /licences.
• A software bill of materials is produced for the firmware, cloud, web, hub screen, app and Android apps, and the build fails on a licence the policy forbids.
• The hub’s services run hardened: read-only system, private temporary storage, an explicit device allow-list; the recorder runs alone at the highest priority so nothing else can take a second of video with it.

Encrypted transport and storage

• In transit: TLS 1.2 as the floor and TLS 1.3 offered, for browsers, apps and devices alike. (1.3-only would lock out cameras whose TLS stack is frozen by their maker.)
• At rest: every object storage bucket is private, blocks public access and uses server-side encryption (AES-256); the server’s disks are encrypted; the backup bucket is encrypted and versioned so a bad copy cannot overwrite a good one; secrets live in an encrypted parameter store that only the API’s role may read.
• Signed webhooks: deliveries to your URLs carry a keyed hash you can verify, and a guard refuses private or internal addresses as destinations.

Your account

• Passwords of at least ten characters, stored as salted hashes. Sign-up is proven with a six-digit code that expires in fifteen minutes and allows five tries. A password reset is a single-use link that works for one hour, stored hashed like a password; using one link kills any others, and the response never reveals whether an address has an account.
• Two-factor authentication with an authenticator app: enrolment is proven with a code before it switches on, recovery codes are shown once and stored hashed, and turning it off needs the current password. Kardo staff use two-step sign-in on their own console.
• Rate limiting on sign-in, codes and second factors. Addresses supplied by the client are never trusted.
• Seven roles, each person limited to all or chosen sites — and within them to chosen cameras, doors and screens — enforced by the server in every query and in every answer on its way out. Without video permission a person sees figures and never a picture. Access can be set to end by itself: refused from that minute, switched off within five, audited.
• Web sessions last seven days and are HTTPS-only and unreadable by scripts; a staff session lasts twelve hours.

Tenant isolation, tested

Every table carries the account it belongs to and every query is scoped to it. One automated test walks every API route the running code exposes (438 at the last count) and, as another account’s owner, hub and integration key, asks for your things by id. It checks that no answer carries your data, that your rows are unchanged after every write, that nothing of theirs points at yours, that the platform console refuses a customer credential, and that nothing answers with a server error. It runs against a throwaway database before a release.

Privacy modes and least data

• Per camera: Local only (no picture leaves the building), Events to the cloud (the default), Events and snapshots, or Alert clips too. Local only and metadata-only are enforced at ingest: the cloud strips imagery rather than refuse the event.
• Per account: Kardo AI Cloud, cross-site search, the semantic index and screenshots of screens can each be switched off; a site can refuse screenshots and cloud pictures by itself. Switching the index off deletes it at once.
• Retention is enforced, not advertised: events, alerts, audit entries and Intelligence figures are deleted on schedule, every night, as set out in the Privacy Policy. Evidence you mark is never deleted automatically.
• Search results across sites live in memory for thirty minutes; a photo you search with is not kept; search history is not kept. Faces enrolled at a door are sealed on the terminal.

An audit log that cannot be rewritten

Every account has an audit log of who did what: sign-ins, role, site and device-limit changes, grants and end dates, privacy and retention changes with before and after, exports, support sessions and the video they opened, and changes made on a KardoHub’s own screen (marked as such). Entries are append-only: the application cannot change or delete one, and a database trigger refuses it too. Only the nightly retention job removes entries, after 730 days or the owner’s choice of at least a year.

Support only when you grant it

Kardo support cannot open your account. An owner or manager grants a read-only session for one, four or twenty-four hours, limited to devices unless they also allow video or figures, and can end it at any moment; each session lasts at most an hour and is written to your audit log with what it opened. The platform console shows every open grant and ends it with one button.

Keeping the platform honest

• One event is one event: deliveries from devices are idempotent, so an outage never counts anything twice, and devices keep their data when the cloud refuses a write during a database problem.
• Health checks tell the load balancer the truth; a stuck rules, alert or sweep loop is flagged on the platform console and logged when it recovers.
• Nothing on a screen is invented: a capacity figure appears only after it was measured on that device, and an AI feature only when its model is installed.
• Daily snapshots of the cloud server’s disk are taken. Infrastructure is defined as code and deployed by one script, with alarms.

What is not done yet

Said plainly, so nobody reads more into the above than is there:

• No certification. Kardo holds no SOC 2, ISO 27001 or similar report, and no independent penetration test has been completed. [Owner: confirm, and state any date planned.]
• One region, one availability zone. The cloud runs on a single server in us-east-1. There is no multi-region or multi-zone failover; regional data planes are a later stage of the scale plan. Your sites keep recording and controlling doors when the cloud is down.
• No self-serve export or deletion of a whole account. Both are by request to support today; per-item deletion, retention and CSV export exist in the Service.
• Some measures are built but not yet proven in production at the time of writing: device-made keys, the per-kind device permissions (the owner applies them), the encrypted reader link, and Kardo Intelligence on the camera itself. Each is marked in the product record as built, not shipped, until it is.
• No bug bounty. Reports are welcome at [security contact email]; we will acknowledge them and say what we did.

Last updated 29 September 2026. KardoVision is a product of Kardo.