Security & Privacy at Mobexa

1. Security posture at a glance

2. Compliance, frameworks and certifications

We are honest about where we are. Items below are clearly marked as live, in progress, or planned - we do not advertise certifications we do not hold.

3. Data protection

3.1 Encryption in transit

• All customer traffic terminates on TLS 1.2+ (TLS 1.3 preferred). Legacy protocols (SSL 3.0, TLS 1.0/1.1) are disabled.
• HSTS is sent with a minimum max-age of 1 year and includeSubDomains.
• Internal service-to-service traffic stays on the loopback interface or on private network segments; it is not exposed externally.

3.2 Encryption at rest

• Customer secrets (API keys, SMTP credentials, integration tokens) are stored on encrypted volumes and never logged.
• Off-site backups are encrypted client-side with AES-256 (restic) before they leave the origin host. The provider only sees ciphertext.
• Backup encryption keys are held by Mobexa only; sub-processors cannot decrypt backup contents.

3.3 Tenant isolation

• Every tenant-scoped record carries a tenant_id. Customer requests are filtered server-side; an authenticated customer cannot read a sibling tenant's records even with a guessed identifier.
• Customer-managed integration credentials (SMTP, Webhook, Jira, ServiceNow, Slack and other connectors) are stored in per-tenant configuration overlays. The administrator's global credentials are never exposed to customers.

4. Identity, access and authentication

• Passwords are hashed with bcrypt (work factor ≥ 10). Plain-text storage is forbidden by design - the data model has no "password" column.
• Time-based one-time password (TOTP) two-factor authentication is supported and recommended for admin and operator roles.
• Sessions are bound to a server-side store. Cookies are issued with HttpOnly, SameSite=Strict and Secure. Idle and absolute timeouts apply; suspicious user-agent changes invalidate the session.
• Login attempts are rate-limited per IP and per username; repeated failures trigger an exponential backoff and an alert in the admin console.
• Force-logout is centrally enforceable; an administrator can terminate any active session immediately.

5. Application security

• Output encoding: All dynamic values rendered in HTML pass through context-aware escapers. We do not concatenate user input into HTML.
• CSRF: Every state-changing request requires a per-session CSRF token validated server-side.
• CSP: A strict Content-Security-Policy is sent on every response, with reports posted to /csp-report for monitoring.
• Input validation: Server-side validation is mandatory; client-side checks are convenience only.
• File handling: Uploaded binaries are stored under non-executable paths and analysed inside an isolated sandbox (bwrap with read-only system mounts and no network).
• Dependency hygiene: Known-vulnerability checks run on every release; high-severity advisories trigger a same-day patch process.
• Bot & abuse protection: hCaptcha protects public forms; rate limits guard authentication and contact endpoints.
• Internal SAST/DAST: The Mobexa codebase is scanned using our own engine at every release. Findings flow through the same triage workflow customers use.

6. Infrastructure

• Public traffic enters via a managed CDN/WAF edge that provides DDoS mitigation, TLS termination, and a baseline rule set.
• Origin services are not directly exposed; they are reached only through an authenticated tunnel from the edge.
• Off-site backups are stored on a vetted encrypted object storage provider with object lock retention and an append-only key model, so a compromised origin cannot delete historical snapshots.
• Production hosts run a hardened Linux base. Updates are applied on a defined schedule and out-of-band for high-severity issues.
• Dynamic analysis (running customer binaries) is performed in disposable, network-isolated sandboxes; nothing from a customer binary can reach the host or other customers.

7. Privacy and data subject rights

• We process customer data only for the purposes described in our Privacy Policy and Data Processing Addendum.
• Data subjects can request access, correction, deletion, restriction, portability and objection through our DSAR portal at /legal/data-request. Requests are answered within 30 calendar days (free of charge for the first request per year).
• Customer data residency: production primarily in EU (TR-adjacent), with backup snapshots in EU-region object storage.
• We do not sell customer data and do not use customer-uploaded binaries to train any third-party model.

8. Sub-processors

The following providers process limited customer data on our behalf. Specific vendor names are disclosed in the full sub-processor list which is available on request to existing customers and qualified prospects under NDA via support@mobexa.io. We perform initial due diligence and re-evaluate on a yearly cadence. Customers can request 30-day prior notice of new sub-processors via subprocessor notice.

9. Vulnerability management

• Findings on the Mobexa platform itself flow through the same lifecycle (new → acknowledged → confirmed / false-positive / accepted-risk → closed) that we expose to customers.
• Service-Level Objectives for remediation: Critical ≤ 7 days, High ≤ 30 days, Medium ≤ 90 days, Low at next planned release.
• SLA-breach alerts trigger an automatic notification to the security team.
• The platform is subject to an independent external penetration test on an annual cadence. The current cycle has been completed and findings have been remediated or accepted by the security team in accordance with the SLOs above.
• The latest pentest summary letter (vendor name, scope, methodology, finding counts by severity, remediation status) is available to existing customers and qualified prospects under NDA via support@mobexa.io.

10. Responsible disclosure

We welcome reports from independent researchers. To report a suspected vulnerability:

• Email info@mobexa.io.
• Provide a clear technical description, reproduction steps and the impact you observed.
• Please do not publicly disclose the issue, exploit it beyond what is needed to demonstrate the impact, attempt to access other customers' data, or degrade service availability.

We commit to:

• Acknowledging your report within 3 business days.
• Providing an initial triage (severity, fix plan) within 10 business days.
• Coordinated public disclosure once a fix is generally available, with credit to the reporter unless anonymity is requested.
• Not pursuing legal action against good-faith research that respects the boundaries above.

11. Documents available on request

The following materials are made available to qualified prospects and existing customers under a mutual non-disclosure agreement. Email support@mobexa.io with your company domain.

• Mobexa Security Whitepaper - control deep-dive, network diagram, data flow.
• Data Processing Addendum (DPA) - for self-service execution if you require it before signing the order form.
• Sub-processor list (full) - the public list above, plus any region-specific processors.
• Latest pentest summary letter - available now (executive summary, scope, methodology, severity breakdown, remediation status).
• SOC 2 readiness gap analysis - available while we work toward Type I.
• Business continuity / disaster recovery summary - RPO ≤ 24h, RTO ≤ 4h on Business and Enterprise.
• Security questionnaire - we maintain a current CAIQ-Lite / VSAQ response we can send back the same day.

12. Contact

• General security questions, customer security review: info@mobexa.io
• Trust Center / vendor due diligence requests: support@mobexa.io
• Privacy and DSAR queries: info@mobexa.io or /legal/data-request
• Suspected security incident affecting your account: info@mobexa.io with subject line beginning [INCIDENT].

This page is informational and does not by itself form a contract. Where it conflicts with a signed Master Subscription Agreement, Order Form or Data Processing Addendum, those signed documents govern.