Security FAQ

Last updated: 2026-08-17

Where is our data hosted?

Lexabit is hosted by DigitalOcean in Amsterdam, the Netherlands — the application server, database, and CDN all run in that region, keeping data within the EU.

Is data encrypted in transit and at rest?

All traffic to Lexabit is served over HTTPS (TLS, via Let's Encrypt certificates) with HSTS enabled. At rest, integration credentials are encrypted using AES-256 via the application's encryption layer, and client national identity numbers are column-encrypted. Column-level encryption at rest is currently limited to those two categories; other application data (including transaction records) is protected by access controls and infrastructure-level controls rather than field-level encryption. Encryption keys are application-managed on the production environment; the credential-encryption layer supports key versioning and rotation. There are currently no backups to encrypt — see How are backups handled?

How is our data isolated from other tenants?

Lexabit runs on a single shared application database — it does not use a separate database per customer. Isolation is enforced in the application layer: every request carries an X-Scope header identifying the entity context (tenant, group, project, client, or case), and middleware verifies the authenticated actor can access that scope through structural relationship chains and explicit visibility assignments before any data is returned. See the Security Overview for the full mechanism.

Do you support Single Sign-On (SSO)?

Sign-in via Google and Microsoft is supported using OAuth with PKCE, where enabled. Enterprise SSO federation (SAML or OIDC) is Planned and not yet available.

Do you support two-factor authentication (2FA)?

Two-factor authentication is Planned and not yet available. Today, account security relies on Argon2id password hashing and an automatic lockout after 5 consecutive failed login attempts.

Who at Lexabit can access our data?

Lexabit is a small team; access to customer data in production systems is limited to operations personnel who need it to run and support the platform. Production infrastructure access is key-based and restricted to that same small group, and production deploys run through a controlled pipeline with environment-scoped secrets and approvals. Formal audit logging of privileged (administrative) access to production infrastructure is Planned — it is not yet in place, and we say so rather than imply otherwise.

How are tokens, credentials, and other secrets handled?

Secrets fall into three groups, handled differently:

• Customer bank credentials — never seen or stored by Lexabit; authentication happens at the bank (see below).
• Integration and provider credentials — stored encrypted (AES-256) through a dedicated credential-management layer that supports key versioning and rotation, and logs credential operations to an audit trail.
• API tokens and keys — user sessions and API access use Laravel Sanctum tokens; personal access tokens, application API keys, and OAuth consents can each be revoked by the customer directly in the product, taking effect immediately.

Can we remove a user and their access ourselves?

Yes. Tenant administrators can deactivate or remove users in the product; a removed or deactivated user loses platform access, and their role assignments no longer grant access to customer data. Personal access tokens and application keys created under the tenant can likewise be revoked by the customer without contacting Lexabit.

Is the isolation between customers and cases tested?

Tenant and case isolation is enforced by the entity-permissions system on every request (see how isolation works), and that system is covered by an automated test suite exercising role, permission, visibility, and scope checks, run as part of the development workflow. An external penetration test, which would provide independent validation, is Planned.

Do you have central security logging, monitoring, and alerting?

Partially — and we distinguish honestly between the pieces:

• Application audit logs are In place: integration activity and login metadata are recorded.
• Availability monitoring is In place: a public health endpoint plus per-service health checks, monitored externally, with a public status view at status.lexabit.com.
• Centralized security monitoring and automated alerting on suspicious activity (SIEM-style) is Planned — not yet implemented.

Have you defined RPO and RTO?

Not yet. Lexabit does not run backups today, so publishing recovery objectives would be meaningless — we would rather state that plainly. RPO and RTO will be defined and published together with the planned backup regime and managed-database move, along with the status of recovery testing.

How do you handle vulnerabilities, patching, and security testing?

Today: dependency security auditing and static analysis run as part of the development quality gate before changes ship, and framework/dependency updates are applied through the normal development cycle. Scheduled vulnerability scanning of the running application and infrastructure, formalized patch-management cadence, and an external penetration test are Planned and tracked on the Compliance Roadmap.

How do you handle bank credentials?

Lexabit connects to bank accounts through regulated open-banking providers — currently Enable Banking. Customers authenticate directly with their bank during the connection flow — Lexabit never receives or stores bank login credentials. Bank connections are covered by individual consents, each with its own lifecycle, and expired or revoked consents are enforced automatically. The credentials Lexabit uses to authenticate with our banking providers are encrypted at rest.

Are you ISO 27001 or SOC 2 certified?

Not yet. Lexabit does not hold ISO 27001 or SOC 2 certification directly; our infrastructure provider, DigitalOcean, is independently certified to both. See the Compliance Roadmap for current status and direction.

Have you had a third-party penetration test?

Not yet — an external penetration test is Planned. See the Compliance Roadmap for details.

How are backups handled?

Honestly: Lexabit does not run backups today. A formal backup regime, alongside a planned move to a managed database service, is Planned.

What is your incident-response process?

Lexabit publishes a public /health endpoint and a per-service health check for each core service, monitored externally by an uptime-monitoring service to alert on availability issues. As a data processor, Lexabit is committed to notifying affected customers without undue delay, consistent with our GDPR obligations.

How do you develop software securely?

Production runs on its own dedicated infrastructure, fully separated from the non-production environments. Development and staging are separate deployments — each with its own configuration and data — on shared non-production infrastructure. The underlying framework (Laravel) provides parameterized database queries, CSRF protection, and output escaping by default.

Can we get our data out?

Audit-log export for integration activity is available in-product. The platform also generates on-demand reports and documents, which are access-controlled behind the same permission and scope checks as the rest of the platform. For other data export or erasure requests, contact security@lexabit.com.

How do we report a vulnerability?

Email security@lexabit.com.