Information Security Addendum
Last updated: July 29, 2026
1. Purpose
This Information Security Addendum (“Addendum”) describes the technical and organizational measures Magdox Private Limited implements to protect Customer Data processed through the FDIE cloud platform. It is incorporated by reference into our Terms of Service and, where applicable, our DPA. Described controls apply across all FDIE SaaS plans unless noted otherwise.
2. Encryption
- In transit: all connections to the FDIE platform are encrypted via TLS (TLS 1.2+ / TLS 1.3). Database connections between the application and PostgreSQL also require TLS encryption.
- At rest: firmware images, analysis results, and account data are encrypted at rest on our infrastructure providers’ managed storage and database services using AES-256.
- Secrets management: database credentials and other sensitive secrets are never hardcoded into application configuration. They are issued dynamically, scoped to a short lease, and automatically rotated through a dedicated secrets management system, reducing the blast radius of any single leaked credential.
3. Authentication and Access Control
- Multi-factor authentication: FDIE supports TOTP-based MFA and WebAuthn/passkey-based authentication for user accounts.
- Passwordless sign-in: FDIE supports passwordless sign-in via a time-limited, single-use email code as an alternative to a stored password.
- SSO/SAML: Enterprise plans support SAML-based single sign-on with the customer’s own identity provider, centralizing onboarding and offboarding.
- Role-based access control (RBAC): permissions within an organization (who can upload firmware, view results, manage users, or export reports) are governed by role, not left to ad hoc access.
- Multi-tenant isolation: every firmware image, analysis result, and report is scoped to the owning organization at the database layer. FDIE’s data model enforces this isolation on every query: one organization’s data is never visible to another.
4. Application Security
- CSRF protection: state-changing requests are protected using a double-submit token pattern.
- Secure defaults in production: the platform refuses to start in a production configuration with a weak or default signing secret, rather than silently running with reduced security.
- Audit logging: sensitive actions (uploads, exports, user and role changes, authentication events) are recorded in an audit log available to organization administrators.
5. Analysis Engine Integrity
- FDIE’s analysis engine performs deterministic, rule-based static analysis. It does not use generative AI or machine learning to produce findings, and Customer Data is never used to train any model.
- Analysis results are reproducible: the same firmware image analyzed twice produces identical findings, and every finding traces back to a specific binary, string, or configuration value a customer can independently verify.
6. Availability and Resilience
Availability commitments for SaaS deployments are described in Terms of Service Section 13 and, for Enterprise customers, in the applicable Order Form.
7. Backup and Disaster Recovery
7.1 Region Strategy
FDIE is hosted on Google Cloud Platform (GCP) with Mumbai (asia-south1) as the primary region and Delhi (asia-south2) as the designated disaster recovery (DR) region. Both regions are located in India, ensuring all Customer Data remains within Indian jurisdiction in compliance with the Digital Personal Data Protection Act, 2023 (DPDPA).
7.2 Data Backup
| Data Type | GCP Storage | Backup Method | Frequency |
|---|---|---|---|
| Firmware images, SBOMs, VEX, and CBOM exports | Object Storage (Standard tier) | Cross-region replication to Delhi | Near real-time (async) |
| PostgreSQL database (accounts, scan results, metadata, audit logs) | Managed database storage (Cloud SQL for PostgreSQL) | Automated backup with point-in-time recovery (same-region); cross-region copy to Delhi is planned and not yet active | Continuous (point-in-time recovery) plus daily backup |
Application code is not backed up via storage replication; it is redeployed from source control on DR activation.
7.3 Disaster Recovery Architecture
FDIE uses a Pilot Light DR model:
- A minimal standby compute instance is pre-configured and stopped in the Delhi region at all times.
- Object Storage data is continuously replicated to Delhi and is immediately available without any restore step.
- In the event of a primary region failure, the standby compute is started, the latest database backup is restored to a new managed database instance, and DNS is updated to point to the Delhi endpoint.
- Once the primary region recovers, data is re-synced and traffic is failed back.
7.4 Recovery Objectives
| Plan | RPO (Recovery Point Objective) | RTO (Recovery Time Objective) |
|---|---|---|
| Business | 24 hours | 4 hours |
| Enterprise | 1 hour | 1 hour |
RPO is the maximum window of data loss in the event of a declared disaster. RTO is the maximum time from disaster declaration to service restoration.
Enterprise RPO and RTO commitments require hourly incremental backups and a warm standby compute instance in Delhi, which are provisioned as part of the Enterprise Order Form. Business tier commitments are met through daily incremental backups and the Pilot Light standby described above.
Enterprise customers with a custom primary region under this DPA’s sub-processor terms have their DR region and RPO/RTO commitments specified in their own Order Form, not the default Mumbai/Delhi pair described above.
8. Certifications and Audits
Magdox does not currently hold formal security certifications. We will not claim a certification we have not earned. The controls described in this Addendum (encryption, access control, audit logging, multi-tenant isolation, and disaster recovery) are operational today. Formal certification is the independent verification of those controls, not a prerequisite for them.
Our certification roadmap (ISO 27001 and SOC 2 Type II) and current status are published on our Security and Trust page and updated as they progress.
PCI DSS scope. All payment card data is handled exclusively by 2Checkout (Verifone) through their hosted checkout page. Magdox does not collect, transmit, process, or store cardholder data. As a result, Magdox is out of PCI DSS scope as the upstream merchant; card data security compliance rests with 2Checkout (Verifone) as our authorized payment processor and Merchant of Record.
9. Vulnerability Reporting
We welcome reports from security researchers. See our Responsible Disclosure Policy for our contact, SLAs, and safe harbor terms.
10. Changes to This Addendum
We may update this Addendum as our security architecture evolves. Material changes will be communicated the same way as changes to our Terms of Service.