Information Security Addendum

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. The SaaS baseline and the scope of each hosting profile are described below. Dedicated and on-premise deployments require an agreed allocation of responsibilities and configuration in the Order Form; they do not inherit every hosting or recovery statement automatically.

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: production secrets must be managed outside source code and access restricted to the services and operators that need them. The secrets-management integration supports scoped, leased credentials and rotation. The methods, lease periods and rotation arrangements depend on the deployment and must be recorded in its configuration; not every credential is necessarily dynamically issued.

3. Authentication and Access Control

• Multi-factor authentication: FDIE provides authenticator (TOTP) and email two-factor options. Available methods and organization requirements are shown in account settings.
• Passwordless sign-in: FDIE supports passwordless sign-in via a time-limited, single-use email code as an alternative to a stored password.
• Single sign-on: Enterprise organization setup supports OpenID Connect (OIDC) with a configured identity provider. Provider configuration and claim mapping must be agreed during setup; direct SAML and passkey management are not part of this advertised setup.
• 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. Organization-scoped authorization and data access are the isolation mechanisms. This description is not an independent verification of every query or a guarantee that an authorization defect cannot occur.

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 and sandboxed dynamic analysis in which the firmware’s own binaries are executed in an isolated environment with no network egress. It does not use generative AI or machine learning to produce findings, and Customer Data is never used to train any model.
• Results depend on the firmware, engine build, rules, configuration, feed context and stage coverage. Recorded context helps reviewers distinguish an earlier assessment from a reassessment with new inputs. Older records may lack complete immutable stage/feed snapshots; they must not be represented as fully reproducible assessments. Runtime observations can vary between runs. Findings include available supporting evidence and limitations, rather than a guarantee that every conclusion has been independently verified.

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 cloud hosting is provided on Oracle Cloud Infrastructure (OCI) in India only. The deployment arrangement is agreed in the Order Form before provisioning. Customer Data at rest (account data, audit logs, firmware images and analysis results) is stored in India, subject to the provider and integration exceptions described below. Customers that need their data kept outside India can deploy FDIE on-premises in their own environment. Storage location alone does not establish compliance with data protection law.

The cloud deployment uses India West (Mumbai) (ap-mumbai-1) as its primary region and India East (Hyderabad) (ap-hyderabad-1) for disaster recovery. The error-monitoring and sign-in geolocation paths listed in the DPA sub-processor table involve processing outside India; transactional email, including report files a user chooses to email, is sent through Zoho ZeptoMail in India. None of these paths is intended to transmit uploaded firmware images. Region-specific recovery arrangements are described at the end of Section 7.4.

7.2 Data Backup

The following table describes the India deployment profile. Other deployments document their own storage, backup locations, frequency and retention schedule.

Object Storage replication is not an independent point-in-time backup and can replicate changes or deletions. Cross-region database backup copies are planned and are not yet active.

Backup creation frequency is separate from how long copies are retained. This public schedule does not specify a verified universal backup-expiry period. The deployment documentation must state retention, expiry, restore access and how deletion is reapplied after restoration; request it before relying on a deletion or recovery deadline.

Application code is not backed up via storage replication; it is redeployed from source control on DR activation.

7.3 Disaster Recovery Architecture

The India deployment profile uses a Pilot Light DR model:

• A minimal standby compute instance is pre-configured and stopped in the Hyderabad region at all times.
• Replicated Object Storage data can be accessed in Hyderabad after failover setup; availability depends on the most recently completed replication and service health.
• In the event of a primary region failure, the standby compute is started, the latest database backup is restored to a new database instance, and DNS is updated to point to the Hyderabad endpoint. Until the cross-region database copy noted in 7.2 is active, the backup restored in Hyderabad must be retrieved from Mumbai, so a failure that makes Mumbai’s storage unreachable also delays database recovery; the Object Storage tier (firmware images and exports) is already replicated and is not affected by this gap.
• Once the primary region recovers, data is re-synced and traffic is failed back.

7.4 Recovery Objectives

RPO (Recovery Point Objective) is the target recovery-point interval; RTO (Recovery Time Objective) is the target restoration interval for the agreed failure scenario. These are objectives, not unconditional maximums. Contractual scope, measurement and remedies require an Order Form.

Scope of the India shared-deployment objectives. The 24-hour / 4-hour objectives apply to a database or compute failure inside the primary (Mumbai) region, recovered from point-in-time backups and the standby described in Section 7.3. For a failure that makes the whole Mumbai region, including its storage, unreachable, Object Storage data (firmware images and exports) is already available in Hyderabad, but the database restore depends on retrieving the Mumbai backup (Section 7.3). Until the cross-region database copy noted in Section 7.2 is active, Magdox does not commit to a recovery time objective for that scenario; this Section is updated when it is. These objectives are contractual commitments only where an Order Form incorporates them.

The dedicated-deployment commitments require hourly incremental backups and a warm standby compute instance, which are provisioned as part of that Order Form. The India shared-deployment profile uses the arrangements described above; actual achievement depends on backup availability and a tested recovery procedure. This text is not evidence of a completed recovery test.

An on-premise deployment runs in the customer’s own environment and location. Its backups, disaster-recovery locations and RPO/RTO terms are the customer’s responsibility unless the Order Form records otherwise; the Mumbai/Hyderabad arrangements above apply to the cloud deployment only.

8. Certifications and Audits

Magdox does not currently hold formal security certifications. We will not claim a certification we have not earned. This Addendum describes the service baseline and identifies deployment-dependent arrangements and recovery gaps. Deployment evidence and independent assessment are distinct from a published control description. A SOC 2 Type II report is an attestation report, not a product certification.

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.

Billing. Subscriptions are invoiced directly by MAGDOX Private Limited and settled by bank transfer; the Service has no online payment flow. Do not upload payment-card data for analysis.

9. Vulnerability Reporting

We welcome reports from security researchers. See our Responsible Disclosure Policy for our contact, response targets, 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.