Security
Effective 2026-09-26.
How axonia protects the data it holds, and where it falls short. Everything here is in place today; nothing planned is described as done.
Certification
axonia holds no security certification. It is not ISO 27001 certified, has no SOC 2 report, and has not had an independent security audit. It is built and operated by one person, Gabriel Dinant, in Switzerland.
Where data lives
The application, its database and its sign-in service run on Railway, in Amsterdam. Every request reaches the application through Cloudflare, and the application refuses any request that did not come through it. Uploaded files, such as avatars and images, are kept in Cloudflare R2 storage. Every company involved is named in the privacy notice.
Encryption in transit
Every connection to axonia uses HTTPS, and browsers are instructed never to fall back to plain HTTP. Outgoing mail leaves over an encrypted connection.
Keeping organisations apart
Row-level security in the database separates one organisation’s data from another’s, underneath the checks the application itself makes. The application connects with a database role that cannot bypass it.
Signing in
An organisation can have its members sign in through its own identity provider, over OpenID Connect or SAML, Microsoft Entra ID included, and can provision and remove them through SCIM 2.0. Individuals sign in with Google or GitHub. axonia does not enforce multi-factor authentication itself: it comes from the identity provider used to sign in.
The browser never holds a long-lived credential. The sign-in is kept in a sealed cookie that the page cannot read, and refresh tokens are replaced on every use. Access tokens for integrations are stored only as hashes and can be revoked at once, and directory provisioning tokens always expire.
Permissions
Roles are scoped to one organisation. An administrator cannot grant or remove a permission they do not hold themselves, and an organisation cannot lose its last owner.
In the browser
Every page carries a strict content security policy: the browser may load code only from axonia itself and from the payment provider, whose form appears only on the payment page. There are no analytics, advertising or session recording scripts.
Changes and dependencies
Every change passes an automated build before it can reach production, covering the full test suite and static security analysis, with dependencies installed only from pinned lockfiles. Dependencies are checked for updates every week.
Backups
The database has point-in-time recovery over a rolling window of roughly four weeks.
Getting data out, and deleting it
A member who signed up directly can download their data and erase their account from Account settings, in Privacy. An administrator of an enterprise account can export the organisation’s personal data. When an organisation’s account is closed, its data and its members’ sign-in accounts are deleted, and database backups roll past them within roughly four weeks.
Known limitations
- There is no availability commitment and no status page.
- There is no formal incident response process.
- Multi-factor authentication is not enforced by axonia itself.
- A standard data processing agreement is not published yet; an organisation that needs one can ask at privacy@axonia.dev.
Reporting a vulnerability
Reports go to support@axonia.dev, with enough detail to reproduce the issue.