Security
We sell security. We can’t be the breach.
Kandaro sensors run inside your network, and our platform holds intelligence about your environment. This page describes, plainly, how we protect both. It applies to every Kandaro product.
Sensors receive data, never code
Nothing we send can make a sensor execute anything.
MFA for everyone
Passkeys or TOTP for every user; staff use passkeys only.
Isolation in the database
Postgres row-level security behind every tenant query.
EU-hosted, GDPR
EU hosting, local AI by default, minimal retention.
Sensor trust boundary
A sensor lives inside your network. Compromising Kandaro must never become a foothold in yours, so the sensor is designed to trust us as little as possible.
- Data only, never code. The backend sends a sensor strictly validated configuration (profile, ports, ignore lists, honeycred hashes). Unknown fields are rejected, and the sensor has no feature that executes instructions it receives.
- Outbound only. The sensor calls our API over TLS 1.2+. It never opens a management port for us, and certificate validation cannot be switched off in production builds.
- Signed images, no silent updates. Sensor images are signed with cosign and ship with an SBOM. You pin a version or digest; the sensor never updates its own code. The Console tells you when an update is available.
- Hardened container. Non-root, all capabilities dropped except binding low ports, read-only filesystem,
no-new-privileges, default seccomp. Never privileged, never the Docker socket. - Short-lived enrolment, revocable keys. Enrol tokens are single-use and expire after 24 hours. Sensor API keys are stored only as hashes, compared in constant time, and can be rotated or revoked from the Console.
Accounts & sessions
- MFA is required for every user. Passkeys (WebAuthn) or TOTP, with one-time recovery codes. Kandaro staff use passkeys only.
- Passwords are hashed with argon2id and checked against known breached passwords using the k-anonymity range API, so your password never leaves our servers.
- Short-lived access tokens kept in memory; refresh tokens are rotated on every use, and a replayed token revokes the whole session.
- Per-IP and per-account throttling and temporary lockouts. You can list and revoke your active sessions.
Tenant isolation
Your events are visible to your organisation only, enforced twice:
- In the application: every query is scoped to the organisation from your verified session, never from request input.
- In the database: PostgreSQL row-level security on every tenant table. The application’s database role cannot bypass it.
- Access is denied by default: every endpoint has to declare which roles may call it, and one that declares nothing answers 403. Tests check that declaration for staff and customer routes.
- Staff access is behind an additional access gateway with hardware keys. Support impersonation is read-only by default, time-boxed, and visible in your own audit log.
Attacker data is treated as hostile
Everything a honeypot records was written by an attacker, and attackers know it will be displayed somewhere.
- The Console renders event data as text only. HTML from events is never rendered.
- Slack, email and other notifications escape attacker strings for each platform, so a username can’t mention
@channelor inject links. - Our AI pipeline fences attacker data off from instructions, accepts only schema-shaped output and applies a rule-based severity floor that the model can raise but never lower.
Data protection & GDPR
- EU hosting. The platform runs in the European Union.
- Encryption. TLS for everything public; encrypted disks; backups encrypted before they leave the host. Sensitive fields such as alert-channel secrets and opt-in captured passwords get an additional layer of per-organisation AES-256-GCM encryption.
- Captured credentials are masked by default. We store a masked value and a keyed hash, not the password an attacker (or a colleague) typed.
- AI stays local by default. Event summaries are produced on our own infrastructure. Cloud AI providers are opt-in per organisation, with a clear notice that data then leaves our infrastructure.
- Retention. Events are kept 90 days by default (configurable). Deleted organisations are purged within 30 days; backups age out after 35 days.
- Your rights. Export your organisation’s data as JSON, or delete it. A data processing agreement (DPA) and our sub-processor list are available on request.
Sub-processors
Stripe (payments), Resend (email), Cloudflare (network edge), our EU hosting provider, and, only if you opt in, the cloud AI provider you choose.
Infrastructure
- No inbound ports: public traffic arrives through Cloudflare with a managed WAF, rate limits, HSTS and TLS 1.2 minimum.
- Segmented networks: databases and the AI runtime sit on internal-only networks with no route to the internet.
- Hardened containers (non-root, read-only, all capabilities dropped) and least-privilege database roles.
- Strict security headers and Content Security Policy on every site, including this one.
- Supply chain: dependency release-age policy, frozen lockfiles, dependency, secret and image scanning in CI, and hardware-key MFA on every vendor account.
Assurance
- Independent penetration test of the Console, API, sensor and infrastructure before public launch, then at least yearly and after major changes. Critical and high findings are fixed and retested before launch.
- ISO 27001-aligned. We run our security management to ISO 27001 controls (risk register, access reviews, supplier register, incident and backup procedures). We are not certified today.
- Append-only, hash-chained audit log covering logins, MFA changes, keys, sensors, alert channels, billing, exports and staff impersonation.
- Documented incident response, including GDPR breach notification within 72 hours.
Vulnerability disclosure
Found a vulnerability in Kandaro? We want to hear about it. Send it through the contact form (topic “Security report”) with a description, the affected component, and steps to reproduce. Our security.txt has the details. We read reports in English and Dutch.
Our commitment
- We acknowledge your report and keep you informed while we fix it.
- We credit you publicly once it is fixed, if you would like that.
- Safe harbour: if you act in good faith and within these rules, we will not pursue legal action against you for your research.
Please
- Test only against your own account and organisation; never access other customers’ data.
- No denial of service, spam, social engineering or physical attacks.
- Give us reasonable time to fix the issue before you disclose it publicly.
Note: sensors deployed by customers are honeypots. Attacking a customer’s decoy is attacking that customer’s network and is out of scope.
Need a security questionnaire, DPA or more detail for your vendor review? Ask us through the contact form.