Security

Data in transit

Devices send telemetry to regional collectors over HTTPS only. Collectors accept TLS 1.2 and 1.3 with modern cipher suites and reject plain HTTP for data. Traffic between collectors and storage regions travels over mutually authenticated TLS on private links. Certificates are rotated automatically and rotations are announced on the status page when they require draining a collector.

Data at rest

Telemetry is stored encrypted with AES-256 in the storage region chosen for the project. Backups are encrypted with separate keys and kept in the same region. Keys are managed by the infrastructure provider's key management service and rotated yearly.

Collectors

Collectors are the only part of Gatepost that is reachable from arbitrary devices, so they are built to expose as little as possible:

• They are stateless. A batch is validated, acknowledged and forwarded within seconds; nothing is kept on the collector's disk beyond a short in-memory queue.
• They expose exactly the ingest endpoints, /health and the /diagnostics page. There is no endpoint on a collector that returns customer data.
• They are deployed from identical images, receive no interactive access in normal operation, and are replaced rather than patched.
• They run in multiple locations per region so any one of them can be drained without affecting ingest.

Project keys

Project keys are write-only credentials. A key can add telemetry to one project and nothing else, which is why shipping it inside an app is expected and safe. Keys can be rotated at any time from the console; the previous key stays valid for 24 hours so releases already in the stores are not cut off. Ingest is rate limited per key, and unusual volume triggers an alert to the project owners.

What the SDK does not collect

The SDK is designed so that personal data does not reach us in the first place: no request or response bodies, no headers, no screen contents, no advertising identifiers, no precise location. A scrubber masks email addresses, phone numbers, card numbers and token-shaped strings in crash messages and custom attributes before upload. The full list is in data and privacy.

Access control

• Console access uses passwords with mandatory two-factor authentication, or SAML single sign-on on the Business plan and above.
• Roles are owner, admin, member and viewer, assigned per organisation and per project.
• Employee access to customer data is limited to support engineers, granted per case, logged and reviewed monthly.
• The audit log on the Business plan records every configuration change and every data export.

Development practices

All changes are reviewed by a second engineer before deployment. Dependencies are scanned for known vulnerabilities on every build. SDK releases are signed, and the Android artifacts are published with checksums that the Gradle plugin verifies. We run a third-party penetration test of the console and ingest platform once a year; the summary is available to Business and Enterprise customers under NDA.

Compliance

We sign a data processing agreement with customers under the GDPR and confirm storage location for customers under Russian Federal Law 152-FZ. We do not yet hold a SOC 2 report; the audit is in progress and we expect the Type I report in the first half of 2027.

Reporting a vulnerability

If you believe you have found a security issue in the SDK, the collectors or the console, write to security@mustgate.org. Include the steps to reproduce and, if possible, the SDK version or the collector host involved. We acknowledge reports within two business days and keep you informed until the issue is fixed.

We do not pursue legal action against researchers who act in good faith: test only against your own projects, do not access other customers' data, and give us reasonable time to fix before disclosing. Our contact details are also published in /.well-known/security.txt.