Security Controls
Last updated: 2026-08-17
This page lists Lexabit's security controls with an honest status for each. Planned means the control is on our roadmap, not live today — nothing planned is presented as current. Every status below traces to an internal evidence inventory reviewed against the current codebase and infrastructure.
Data Security
| Control | Statement | Status |
|---|---|---|
| Encryption in transit | All traffic served over HTTPS (TLS, via Let's Encrypt certificates) with HSTS enabled | In place |
| Credential encryption | Integration credentials encrypted with AES-256 via the application's encryption layer | In place |
| Sensitive-field encryption | Client national identity numbers are column-encrypted | In place |
| Credential key management | Credential encryption supports key versioning and rotation; keys are application-managed | In place |
| Database encryption at rest | Arrives with the planned move to a managed database service | Planned |
| Backups | No backup regime today; planned together with the managed-database move | Planned |
| Recovery objectives (RPO/RTO) | To be defined and published with the backup regime and recovery testing | Planned |
Infrastructure Security
| Control | Statement | Status |
|---|---|---|
| EU data residency | All hosting in DigitalOcean Amsterdam — droplet, database, object storage, and CDN | In place |
| Environment separation | Production on dedicated infrastructure, fully separate from non-production; dev and staging as distinct deployments with their own configuration and data | In place |
| Availability monitoring | Public health endpoint, per-service health checks, and external uptime monitoring | In place |
| Background processing | Sync, transaction auditing, and health monitoring run on isolated, database-backed queues | In place |
| Managed database | Migration to a managed database service, within the same provider project | Planned |
Access Control & Product Security
| Control | Statement | Status |
|---|---|---|
| Tenant isolation | Entity-scoped access control enforced across the v1 API (four-layer model) | In place |
| Fine-grained permissions | Role-based and per-entity permission checks on individual actions | In place |
| Password hashing | Argon2id | In place |
| Account lockout | 5 consecutive failed login attempts trigger a 15-minute lockout | In place |
| Login rate limiting | Per-IP throttling on login and password-reset endpoints | In place |
| Secure session cookies | Secure, HttpOnly, and SameSite attributes set | In place |
| API authentication | Token-based (Laravel Sanctum) for SPA sessions and application API keys | In place |
| OAuth sign-in | Google and Microsoft sign-in, where enabled | In place |
| Two-factor authentication | Not yet available | Planned |
| Enterprise SSO (SAML/OIDC federation) | Not yet available | Planned |
| User deprovisioning | Tenant administrators can deactivate or remove users directly in the product | In place |
| Token & key revocation | Personal access tokens, application API keys, and OAuth consents are customer-revocable | In place |
| Connected-app constraints | App permission grants hard-capped to a connector-defined allowed set, fail-closed | In place |
| Report & document access control | Generated reports and documents are permission- and scope-gated | In place |
| Private media storage | Signed-URL storage for uploaded profile media | Planned |
Banking Data & PSD2
| Control | Statement | Status |
|---|---|---|
| Consent-based account access | Bank access via authorized open-banking providers; authorization happens at the bank, by the account holder or an entitled party — Lexabit never sees online-banking credentials | In place |
| Individual consent lifecycle | Individual consents, each with its own status and lifecycle | In place |
| Consent expiry & renewal | Consents expire and are renewed through dedicated flows | In place |
| Provider credential encryption | Lexabit's own provider credentials are encrypted at rest | In place |
| Scoped banking data | Bank account and transaction data are behind the same entity-permission scoping as the rest of the platform | In place |
Security Operations
| Control | Statement | Status |
|---|---|---|
| Application audit logs | Integration activity and login metadata recorded | In place |
| Controlled deployments | Tag-based production deploys through a pipeline with environment-scoped secrets and approvals | In place |
| Dependency & code security checks | Dependency security audit and static analysis in the development quality gate | In place |
| Privileged-access audit logging | Formal logging of administrative access to production infrastructure | Planned |
| Central security monitoring & alerting | SIEM-style monitoring and automated alerting on suspicious activity | Planned |
| Scheduled vulnerability scanning | Recurring scanning of application, APIs, and infrastructure | Planned |
Privacy & Assurance
| Control | Statement | Status |
|---|---|---|
| GDPR roles | Customer is data controller; Lexabit (Lexabit AB / Lexabit ApS per contract) is data processor | In place |
| Data-map transparency | Processed data categories are published, including registry-sourced data | In place |
| Data subject requests | Handled via security@lexabit.com | In place |
| Data Processing Agreement | Standard DPA template — today, data-processing terms are agreed directly with each customer during onboarding | Planned |
| Privacy policy | Not yet published | Planned |
| External penetration test | Not yet conducted | Planned |
| Certifications (ISO 27001 direction) | See the Compliance Roadmap for current status and direction | Planned |
For narrative detail on how these controls work together, see the Security Overview. For committed direction and target dates as they're set, see the Compliance Roadmap.