Page · Security & compliance

How Kimezu defends the sign-in.

Identity infrastructure is judged by how it behaves on the worst day, not the best. This page is the long-form list of what Kimezu defends against, how, and what's contractual versus aspirational.

Audit

HMAC-SHA-256 · external verify

Hashes

Argon2id · m=64MB

Region

EU-only by default

Authentication security

How Kimezu protects the sign-in surface.

Authentication credentials are the most sensitive surface in the system. Kimezu's approach is defensive depth (defaults that are hard to weaken, plus controls operators can tune).

m=64MB · t=3

Argon2id password hashing

Memory-hard hashing at m=64MB, t=3, p=1 by default. Operators can tune upward; we never accept downward changes that would weaken hashes.

fail-closed

Per-account rate limit

Fail-closed exponential back-off on failed logins. Account lockouts are reversible only through a verified support workflow.

tarpit + honeypot

Per-IP rate limit

Distinct from per-account. Tarpit on probe patterns (credential stuffing, password spraying); honeypot tokens silently trigger alerts when used.

TOTP + recovery

MFA via authenticator app

TOTP enrolment + signed-email recovery codes. SMS is not offered. WebAuthn / passkeys are on the roadmap (see Platform > Roadmap).

configurable

MFA policies are per-tenant

Operators set the policy (required for admins, optional for users, or required for everyone). Recovery is signed-email-only.

RS256 · 2048-bit

JWT signing

Tokens are signed with 2048-bit RSA. Public keys published via JWKS; rotation cadence is 24 hours by default, on-demand on operator action.

15m / 30d

Short-lived access tokens

15-minute access, 30-day refresh by default. Refresh rotation is enforced; replay of a refresh token triggers revocation of the whole session family.

MFA enrolment (TOTP only, recovery by signed email).

Operators set the policy per tenant; users enrol with any RFC 6238 authenticator app. SMS is intentionally not offered. Recovery codes are issued at enrolment and re-issued only through a signed-email workflow.

auth.kimezu.com/mfa/enroll

Kimezu MFA enrolment — TOTP setup with signed-email recovery codes

Authorization

Authorization decisions evaluate centrally; enforcement runs in your app.

Authorization in Kimezu is a single function call per request, with the policy evaluated centrally and the enforcement happening in your application. This separation is the source of most of the strong guarantees we make.

Permissions in Kimezu are fine-grained statements about actions on resources, evaluated in context: who is acting, on behalf of what owner, in which application. The session JWT carries the effective can array, applications read it and decide locally without an RPC.

When a permission changes (a role is removed, a group membership ends, an agent is revoked), Kimezu invalidates the affected refresh tokens. Within fifteen minutes (or instantly via webhook push) the change has reached every connected app. There is no synchronization job; there is no "eventually consistent" identity state.

A user who is no longer a member of a group should not be a member of that group anywhere.

Principle of least privilege is enforced at grant time, not at runtime. Agents and delegated identities can never receive permissions their owner does not hold; the API call to grant such a permission is rejected before it ever produces a token.

DECIDE Authorization check

// Application asks Kimezu before doing the thing.

POST /v1/authz/decide
Authorization: Bearer <session>

{
  "action": "publish:article",
  "resource": "art_19f2",
  "owner": "grp_press_eu"
}

// → 200 { "allow": true, "reason": "editor-role" }
// → 403 { "allow": false, "reason": "missing-grant" }

// Most apps don't call this every request, the
// "can" array on the JWT is enough. Use /decide
// for ownership-aware authorization on hot paths.

Schematic · The authorization split (Kimezu decides, your app enforces).

Data residency

Where the bytes physically live.

Region is a configuration choice per tenant and a contractual one for the operator. Defaults are deliberately conservative.

a.Two EU primary regionsEach tenant pins to one region; failover is to a secondary site within the same jurisdiction. Specific data centres listed in the Subprocessors section below.EU only

b.Backups stay regionalDaily encrypted snapshots, 30-day retention, replicated only within the tenant's region. No cross-region replication unless contractually specified.30d · in-region

c.No transatlantic transfersKimezu hosted has no US infrastructure. Self-hosted plans run on your hardware, so this becomes a choice you make and we contractually advise on.0 hops

d.Per-tenant encryption keysEach tenant's identity data is encrypted with a tenant-scoped KMS key. Operator-tier and above can BYOK on request; Self-hosted plans always BYOK.AES-256 · KMS

e.Retention is configurableSessions, audit entries and transaction records have separate retention policies. Audit is minimum 7 years for operator-tier and above, configurable up.7y default

f.Right to erasure in the schemaErasing a user means their PII is replaced with deterministic placeholders and the audit log records the action. Aggregates and references survive; identity does not.Art. 17

Audit & observability

An audit log you can verify externally.

Audit logs only matter if you can prove they haven't been tampered with. Kimezu's chain is HMAC-SHA-256 and the head is published hourly, any operator can verify without trusting us.

Every event that matters (sign-in, sign-out, permission grant, key rotation, agent revocation, tenant configuration change, payment-profile update) is recorded as a single entry. Each entry references the hash of the previous entry, so the whole log is a chain.

The HMAC key is tenant-scoped and never leaves the tenant's region. The chain head (the hash of the most recent entry) is published hourly to a separate observable endpoint. Anyone holding a copy of your audit log can verify its integrity by recomputing the chain and comparing against published heads.

Audit exports are available as CSV or JSONL with a stable schema. The data is shaped to drop into a SIEM without transformation (Splunk, Datadog, Sumo, or a humble Postgres table all work). We publish parsers for the common destinations.

AUDIT One entry

{
  "seq": 182_413,
  "ts": "2026-05-14T08:21:04Z",
  "tenant": "rozuro",
  "actor": "usr_8f2b3e1c",
  "event": "session.create",
  "app": "rozuro.com",
  "ip": "203.0.113.42",
  "method": "magic-link",
  "prev_hash": "d4f1..ab",
  "hash": "71e0..3c"
}

// hash = HMAC_SHA256(tenant_key,
//          prev_hash || JSON.minimal(entry))

Schematic · The HMAC chain. Each entry's hash includes the previous one. Tamper any row and the chain breaks at every row after it.

Responsible disclosure

If you found something, we want to know.

Kimezu runs a coordinated disclosure programme. We do not threaten researchers. We pay bounties on the production environment and credit findings publicly with permission.

a.In scopeAnything reachable from *.kimezu.com and the open-source repositories, plus the operator API and tenant authentication surfaces. Tenants' own applications are out of scope, report to them.production

b.Out of scopeDenial-of-service tests on the production environment, social engineering of staff, physical attacks. The sandbox environment is open for DoS testing, please use it.use sandbox

c.Bounty range€100 – €15,000 depending on severity. The full rubric is published in SECURITY.md with worked examples.€100 – €15k

d.Response targetsInitial acknowledgement within 1 business day, severity classification within 3, fix or mitigation timeline within 7. We tell you when we don't meet our targets.1 / 3 / 7

e.Public credit by defaultFindings are credited on our security page with the researcher's preferred name and link, unless they prefer otherwise.opt-out

f.ContactSend PGP-encrypted reports to security@kimezu.com. PGP key fingerprint is on the security page; mirrors on Keybase and our SECURITY.md.PGP

Compliance scope

Compliance scope, contractual versus aspirational.

We are explicit about what Kimezu's contracts cover and what they don't. Compliance theatre is more dangerous than honest scoping.

Standard	What it covers	Kimezu position	Notes
GDPREU general data protection.	Personal data lawful processing	● Native & contractual	DPA + SCC pre-signed
ISO 27001Information security management.	Management system, controls catalogue	● Certified · 2025	Audited annually · BSI NL
SOC 2 Type IIUS-style controls report.	Operational controls over time	● Report on request	NDA required · 12-mo period
EU NIS2EU cybersecurity directive.	Critical / important entity duties	● Scoped in	We are an important entity
HIPAAUS healthcare.	Protected health information	· Self-hosted only	BAA available under Self-hosted
PCI-DSSPayment cards.	Cardholder data	· Out of scope	Processors handle card data, not us
FedRAMPUS federal cloud.	US government workloads	○ Not pursued	Kimezu is EU-first; not a goal

"Compliance" is a floor, not a ceiling. Passing an audit doesn't make a system secure. The defences listed on this page are the day-to-day reality regardless of which standard is in the conversation. The certifications above prove that an outside party agrees with our self-assessment, nothing more, nothing less.

Subprocessors

Where data physically lives and who else touches it.

Operators evaluating Kimezu under GDPR need names, regions and signed documents, not "we sign one before you start." Below is the public list. The DPA and SCCs are downloadable PDFs.

Hosting provider

TODO · region TODO

Email provider

TODO · region TODO

Payment processors

Stripe, Mollie, PayPal (each governs its own data handling per the operator's payment-profile choice). Kimezu records routing and VAT treatment; processors hold the cardholder data.

Physical data centre

TODO · specific facility TODO

DPA

Data Processing Agreement (PDF)

SCCs

Standard Contractual Clauses (PDF)

Incident SLA

We notify operators within 24 hours of confirmed incident detection, with detail sufficient for them to file their own 72-hour GDPR Art. 33 notice.

Erasure

GDPR Art. 17 maps directly to DELETE /api/account, one API call, documented in the API reference. Not a support ticket.

Audit-log retention

Default retention: TODO months

Failed-login retention

Default retention: TODO days

Payment-record retention

7 years, Dutch fiscal requirement for the operator's accounting records.

This page sets no analytics, marketing, or third-party cookies. The sign-in surface for every tenant carries the same posture by default.

Phone, laptop and tablet arranged on a desk (one identity context across multiple devices)

Multi-device desk, one identity across all of them

A tamper-evident chain is only useful if someone, somewhere, has a copy they can verify. The audit log is the document of record (exportable, externally verifiable, on every plan). Most of the work in adopting Kimezu's security posture is doing nothing surprising.

Need depth?

We send the long-form questionnaire on request.

SIG, CAIQ, SCC, DPA, BAA, ISO statement of applicability, we keep them current and send them under NDA. No security-theatre PDFs.

Request the security pack → Read the docs

Contact

security@kimezu.com

PGP key on the security page · mirrored on Keybase.

Bug bounty

€100 – €15,000

Public scope, no NDA, credit on the security page by default.