Security Overview

1 Security approach

AppGantry applies risk-based technical and organisational measures to mobile service offerings, a service for distributing mobile application Builds. Controls are designed around tenant separation, least privilege, secure authentication, protected infrastructure, visibility and recovery. Security changes as the Service and threats evolve.

2 Architecture and tenant access

The Service separates public, application and administrative surfaces. Tenant authorisation checks limit access to organisations, projects, Builds and tester information. Users and administrators receive role-appropriate access. Sensitive administrative functions are separated from ordinary public delivery paths.

The Service runs on Microsoft Azure services for compute, databases, artifact storage, monitoring and supporting infrastructure. This Overview intentionally does not state a hosting region. Where Enterprise BYOSA is enabled, Build artifacts are stored in Customer's own Azure tenant; AppGantry retains operational metadata and access configuration.

3 Authentication and credentials

• Passwords are hashed with Argon2 rather than stored in readable form.
• MFA using TOTP, recovery codes and passkeys is supported.
• Business and Enterprise support SSO/SAML.
• Relevant tokens are stored as hashes; personal access tokens are scoped and revocable.
• Production authentication cookies use Secure, HttpOnly and SameSite=Lax controls.
• Customers control user invitations, roles and removal of organisation access.

4 Encryption and key management

TLS protects supported network connections in transit. Microsoft Azure encryption protects data at rest. Managed identities reduce reliance on embedded credentials, and Azure Key Vault is used for managed secrets and keys where applicable. Access to secrets is restricted by service and role needs.

5 Logging, monitoring and retention

Audit logging records relevant administrative and service events. Operational telemetry, security signals, error reports and traces support troubleshooting, abuse prevention and incident investigation. Logging practices include redaction intended to reduce unnecessary sensitive data.

Customer determines audit retention. Where no different supported setting is agreed or configured, the tier defaults apply, being 90 days for Team, 365 days for Business and 730 days for Enterprise; these defaults are not fixed minimums or absolute caps. Azure Log Analytics retention is 30 days. Sentry error and performance report retention depends on configured provider settings and must be verified against the intended maximum of 90 days. No automated age-based expiry is currently applied to download activity and coarse network metadata, which may remain for the life of the download-event record. The target policy is 24 months and requires technical enforcement; it is not a current maximum.

6 Backups, resilience and recovery

Backups and recovery procedures are used to address accidental loss and restoration of service data. Resilience and disaster-recovery measures are proportionate to the Service architecture. AppGantry does not promise a specific recovery time, recovery point, replication class or availability level unless set out in a separately signed agreement.

Customers should retain source code and independent copies of important Builds. Builds can be retrieved through ordinary Service functionality while access remains available. An individual personal-data export is separate from organisation Customer Content and Build binaries; its download link is available for seven days.

7 Secure development

Development practices include source control, peer review, automated or manual testing as appropriate, dependency management, controlled deployment and remediation prioritised by risk. Changes to infrastructure and application code are subject to access controls. This document does not claim a certification or a fixed penetration-testing cadence.

8 Incident response

Incident procedures support detection, triage, containment, evidence preservation, remediation and recovery. AppGantry assesses legal and contractual notification duties and communicates personal data breaches to affected controllers without undue delay as required by the DPA. No fixed incident response or notification time is promised beyond applicable legal and contractual requirements.

9 Privacy and data handling

AppGantry minimises access to Customer Content and does not inspect or reuse Build binaries for unrelated commercial purposes. Personnel access is limited to authorised needs such as support, security, operations and legal compliance, and is subject to confidentiality duties. Retention and deletion controls are described in the Privacy Policy and DPA.

Subprocessors are selected for defined operational functions and are listed in the Subprocessor List. International processing is subject to applicable transfer safeguards.

10 Employee and privileged access

Internal access follows least-privilege and role-based principles. Managed identities, separated administrative surfaces, authentication controls, logging and review processes help protect privileged operations. Access may be granted temporarily for support or incident work and should be removed when no longer needed.

11 Customer responsibilities

Security is shared. Customer should:

• require strong authentication and enable MFA, passkeys or SSO where appropriate;
• protect passwords, tokens, recovery codes, signing material and administrator accounts;
• give users only necessary roles and promptly revoke access;
• validate recipients and provisioning devices before distributing Builds;
• test Builds and maintain independent source and artifact backups;
• configure retention and, for Enterprise, BYOSA permissions appropriately;
• keep endpoints, browsers, identity providers and Customer Azure resources secure; and
• promptly report suspected compromise or unauthorised distribution.

12 Security reporting

Report suspected vulnerabilities or incidents to security@appgantry.com. Provide the affected URL or function, reproduction details and impact, but do not access other customers' data, disrupt the Service or publicly disclose a finding before it is resolved or the disclosure date set under the Responsible security research section of the Acceptable Use Policy. The default disclosure date is 90 days after the initial report is sent to security@appgantry.com. The researcher and AppGantry may agree a different date. If they discuss a different date but do not reach agreement, AppGantry's selected date applies. AppGantry may subsequently change the disclosure date as required for any reason and will inform the reporter of the change. Security testing must follow the Responsible security research section of the Acceptable Use Policy and any additional scope or method requirements in written authorisation from AppGantry.

13 Changes

This Overview may be updated as controls, providers and risks change. The current version and effective date appear on the document. Material contractual changes are handled under the Terms or DPA, not by this non-contractual Overview.