Last updated 9 October 2026.
1. Scope and operating boundary
MAGDOX Private Limited supplies both products. Code Security scans source locally and accepts requested findings/inventory uploads and authorised snippets. FDIE processes firmware in the selected FDIE deployment, including extracted artifacts and supported runtime work. A control described for one input or execution path must not be assumed to cover the other.
The AWS shared-hosting profile keeps product databases, object storage and regional backups in India. CloudFront delivery and global-service metadata are separate processing paths. CloudFront and its web firewall write their logs in the USA, where they are kept 14 days, and a copy is kept in India for 180 days. Dedicated and customer-operated locations and responsibilities are recorded before provisioning. A local or offline installation requires its own network, identity, patching and recovery controls.
This edition describes the AWS hosting profile that Code Security and FDIE have run on since 5 October 2026. Existing signed orders and processing terms continue until validly changed. Confirm the profile for your organisation before relying on a location, retention period or recovery objective.
2. Transport, storage and secrets
- Hosted browser/API connections use TLS 1.2 or higher. Protect edge-to-origin and database connections for the selected profile; customer-operated deployments must provision and validate their own certificates and trust.
- AWS product databases, customer-content storage, recovery points and operational logs are configured for encryption at rest, using customer-managed AWS KMS keys where supported. Selected AWS log-delivery buckets use S3-managed encryption. Code Security also protects stored integration and authenticator secrets with its application encryption key. Secrets and keys remain outside source code and public artifacts.
- AWS workload roles restrict access to each product's data and Secrets Manager entries. Workloads use role credentials instead of embedded AWS access keys. KMS key rotation and RDS-managed administrator credential rotation are configured; application, identity-provider and SMTP credentials require coordinated rotation with their consumers.
- Application and analysis workloads use private networking, database subnets and scoped security groups. No server accepts SSH or RDP from the internet: administration uses AWS Systems Manager and a private, identity-authenticated management network.
- Every public endpoint sits behind a managed web application firewall applying OWASP-aligned injection and cross-site scripting rules, known-exploit and IP-reputation lists, scanner blocking and sign-in rate limits. Application origins accept only traffic that has passed the firewall. An allowed request still requires application authentication and tenant authorisation.
- Servers receive automated weekly security patching with daily compliance scans. Application images are rebuilt with current operating-system security updates when released and continuously scanned for known vulnerabilities.
- Customer downloads, reports, support packages and backups need equivalent protection in the customer's environment. Metadata can contain sensitive details even when full source files are absent.
3. Identity, authorisation and accountability
| Area | Code Security | FDIE |
|---|---|---|
| Sign-in | Magdox-operated Keycloak in the AWS profile: password, email-code and Google/GitHub sign-in, with optional single sign-on for Enterprise organisations | Magdox-operated Keycloak in the AWS profile; customer-provided identity in agreed customer-operated deployments |
| MFA and sessions | Authenticator or email factor with recovery controls; hosted sessions have 30-minute idle and 12-hour maximum lifetimes; repeated failures lock further attempts for 30 minutes, never permanently and without a CAPTCHA, and networks the account already uses are not locked by other people's failures | Authenticator / email options and production HttpOnly session cookies; configured organisation requirements and session policy apply; repeated failures lock further attempts for 30 minutes, never permanently and without a CAPTCHA, and networks the account already uses are not locked by other people's failures |
| SSO | Enterprise SAML per organisation, off by default, verified email domains and invited membership; SCIM 2.0 provisioning and deprovisioning; only the Super Admin connects the provider, after confirming their identity again | Supported OIDC provider setup included in FDIE plans; on-premises customer supplies the reachable provider; SCIM 2.0 provisioning and deprovisioning; provider changes need the Super Admin's password and, where one is set up, an authenticator code; Google Workspace sign-in only for accounts the organisation's Workspace manages |
| Permissions | Organisation roles, scoped/revocable CLI and CI credentials, device entitlement and sensitive-action checks | Organisation roles for firmware, review, exports and administration; tenant-scoped records |
| Audit | Sign-ins, token activity, uploads, exports, sensitive administration and sign-in locks, recorded in each organisation the account belongs to | Authentication, firmware, export, membership and administrative events, and sign-in locks recorded in each organisation the account belongs to |
Customers administer their members, invitations, IdP, MFA policy and credential revocation. Magdox restricts staff access according to need and records sensitive administration. Tenant-scoped controls describe the intended enforcement boundary, not an independent verification of every query or a guarantee against defects.
Shared identity uses separate application clients, audience checks and product permissions. Signing into one product does not automatically grant membership in the other. The initial identity profile has one host; multiple nodes and a managed Multi-AZ identity database require the HA profile and a validated migration.
4. Input handling and application protection
Code Security's findings endpoints validate bounded JSON against the supported schema; they are not general archive or executable-upload endpoints. FDIE intentionally accepts supported firmware binaries and archives. Its receiving and processing path therefore requires separate size, format, extraction, traversal, resource and sandbox controls; the JSON-only description does not apply to FDIE.
FDIE firmware is uploaded straight to encrypted object storage through short-lived signed URLs, within the plan's size limits, and is never executed on the systems that serve the application. Compliance evidence documents must match their declared type and structure, documents with macros and PDFs that carry scripts, launch actions or attached files are refused, and every file is scanned for malware on arrival; a file found malicious is withheld from download.
State-changing browser operations use product-specific CSRF and session protections. Production configuration must reject insecure defaults where required by the release. Access checks are applied to customer-scoped operations; public documentation does not publish deployment credentials, keys or infrastructure identifiers.
Secure development includes automated tests before each product deployment, dependency and secret checks, vulnerability triage and appropriate release validation. Container base images are pinned by digest, FDIE installs Python packages only from hash-verified files, and every push to the product repositories is scanned for committed secrets. Correctness and security issues can still occur; disclosure, investigation, patches and deployment verification remain necessary.
5. Analysis integrity and execution
Code Security verifies signed rule/engine distribution and uses recorded analysis context to compare results. Customer-facing reports may omit private rule metadata while retaining coverage. Optional AI review is advisory and uses the customer's selected provider. Magdox does not train models on Customer Data.
FDIE uses in-house extraction, component/binary analysis and matching alongside supported runtime and indicator tools such as QEMU, Unicorn and YARA. In the AWS profile each analysis runs as its own job on a dedicated compute host that is discarded when the job ends, with permissions and storage access limited to that job. Firmware code executes only in containers with no network access, a read-only file system, no added privileges and fixed memory, process and CPU limits; a control gate refuses to start any container that does not meet those limits. Static parsing and dynamic execution have different risks, and dynamic execution is enabled only in a deployment with validated isolation for that mode.
FDIE's static findings depend on image, engine, rules, feed and configuration. Runtime observations can vary. Older assessments may lack complete immutable stage/feed snapshots and should not be described as fully reproducible. Neither changed bytes nor a completed job proves remediation or complete coverage.
6. Monitoring, incidents and vulnerability response
Magdox records relevant service/audit events and investigates security reports. Code Security and website Sentry events are filtered and never include session replay; the Code Security dashboard also sends page-load timings with the page path only, and the Code Security API and the website send errors only. FDIE has its own diagnostic configuration with automatic request-body capture disabled. FDIE IP geolocation and optional report email are disclosed in the provider register; they must be reviewed or disabled for disconnected deployments.
The AWS profile configures multi-region CloudTrail management-event collection, selected data-access events, encrypted CloudWatch logs and alarms, GuardDuty, Inspector, Config, Security Hub and IAM Access Analyzer in the defined service scope. Security findings, attack bursts at the firewall, sign-in brute-force attempts, changes to security-sensitive configuration and failed backups alert a monitored security mailbox. Collecting a multi-region audit trail does not create cross-region application failover.
Amazon SES provides transactional email and delivery feedback in the AWS profile. Permanent bounces and complaints feed restricted suppression records; application senders must honour them. Firmware or report delivery by email requires the customer's instruction and appropriate recipient controls.
For a personal data breach affecting Customer Data, notice is without undue delay and no later than 72 hours after awareness, subject to earlier applicable requirements. The DPA defines phased information and assistance. Magdox reports cyber security incidents to CERT-In within six hours of noticing them where the CERT-In Directions of 28 April 2022 require it. The vulnerability disclosure policy applies to authorised research on both products and distinguishes response targets from contractual SLAs.
7. Backup and disaster recovery
7.1 Region and recovery model
Both hosted products run in AWS Asia Pacific (Mumbai), India. Recovery follows an in-region backup-and-restore model: databases are backed up continuously with point-in-time recovery, every protected resource has a daily encrypted recovery point in a retention-locked backup vault, and customer files keep prior versions. Application code and infrastructure are rebuilt from reviewed release artifacts and infrastructure definitions; they are not restored from backups. Product data remains separated by product throughout.
7.2 Backup mechanisms and retention
| Data | Recovery mechanism | Schedule and boundary |
|---|---|---|
| Code Security and FDIE databases | Separate encrypted Aurora PostgreSQL databases with point-in-time recovery | 35-day recovery window; restoration uses the latest available recovery point, not necessarily the time of the incident |
| Application state and workflow records | DynamoDB point-in-time recovery and daily AWS Backup recovery points | 35-day point-in-time window and 35-day daily-backup retention |
| Identity database | Initial profile: encrypted data and system volumes with daily recovery points, plus a consistent daily database dump. HA profile: managed Multi-AZ PostgreSQL with point-in-time recovery | Daily volume recovery points and managed database recovery window: 35 days; object-stored dumps have the additional version lifecycle described below |
| Firmware, reports and uploaded findings | Encrypted, versioned S3 storage; authorised recovery of prior object versions | Lifecycle and customer deletion instructions apply. Versioning is not an independent backup, and no cross-region or cross-account object copy is included in the baseline |
| Application releases and configuration | Reviewed release artifacts and infrastructure definitions used to rebuild services | Rebuilding compute does not restore customer databases, secrets or uploaded content; these need their own recovery procedures |
| Record | Configured lifecycle | Deletion and access limits |
|---|---|---|
| Database recovery and AWS Backup copies | 35 days for the standard point-in-time windows and scheduled recovery points | Restricted to recovery; valid deletion instructions are reapplied after a restore. These periods do not describe S3 versions or audit archives |
| Customer-content object versions | Superseded or deleted S3 versions expire 90 days after becoming noncurrent | Deleting the current object alone can leave recoverable versions. A valid erasure workflow must address all versions, not just hide the live record |
| Single-server identity database dumps | Current copies expire after 35 days; noncurrent versions expire after a further 90 days | Because this bucket is versioned, a retained copy can remain for approximately 125 days, plus service lifecycle processing time; it is not a 35-day total erasure guarantee |
| CloudWatch operational, security and session logs | 180 days in India, including the CloudTrail copy and the logs of the web firewall in front of the applications | Restricted security and operations use. Product activity logs follow their separately stated application schedule |
| Edge access and edge firewall logs | Written in the USA (AWS us-east-1), the only place CloudFront and its web firewall can log, and kept there 14 days; copied to India and kept there 180 days | Access logs hold no IP address, cookies, query strings or referrers. Firewall logs cover only blocked or flagged requests, with credentials and query strings removed |
| Sign-in service events | Sign-in events and records of administrative changes: 180 days | Restricted security use; the identity service deletes older events automatically |
| S3 access and load-balancer logs | Current logs: 180 days; noncurrent versions: a further 1 day | Effective retention is about 180 days, plus lifecycle processing time; minimise identifiers and restrict access |
| Protected cloud audit archive | Current objects: 2,555 days; noncurrent versions: 2,555 days after replacement or lifecycle removal; initial governance retention: 365 days | Effective retention can exceed seven years and approach 5,110 days. These are restricted infrastructure security records, not a general archive of customer firmware or source; the period must be justified for the processing before activation |
| Email delivery suppression | Hashed recipients of permanent bounces and complaints have no automatic expiry | Used to prevent unwanted or failed delivery; reviewed on a verified correction or removal request. A hash is not treated as anonymous data |
The backup vault's retention lock and selected audit-object locks use governance mode: authorised administrators can lift them, so restore and deletion permissions are restricted and separated from application access. Valid deletion instructions are reapplied after any restore, and retained recovery copies are not used for ordinary processing.
7.3 Recovery objectives
| Scenario | Target RPO | Target RTO |
|---|---|---|
| Database error, corruption or accidental change | 15 minutes | 4 hours |
| Loss of the identity server | 24 hours | 4 hours |
| Deleted or overwritten firmware, report or uploaded file | Last stored version | 4 hours |
| Whole-region outage | Not committed in the shared profile | Not committed in the shared profile |
| Dedicated deployment | Agreed in the Order Form | Agreed in the Order Form |
RPO (Recovery Point Objective) is the target maximum data-loss interval for a scenario; RTO (Recovery Time Objective) is the target restoration interval. These are objectives, not unconditional guarantees; contractual targets, measurement and remedies require an Order Form. Same-region redundancy for the identity service and network egress is added by the high-availability profile. No cross-region standby is provisioned in the shared profile, which is why no whole-region objective is given.
7.4 Recovery testing
Recovery is tested, not assumed. On 5 October 2026 a point-in-time restore of the full FDIE production database completed in about five minutes and was verified against the live dataset, and the identity backup was restored and validated separately. Database recovery points are typically less than five minutes old. Restores are repeated after material changes and on a regular schedule, with dated evidence retained. A whole-region recovery has not been exercised.
Dedicated recovery targets require separately ordered and provisioned backup locations, capacity, replication and a tested runbook. Customer-operated FDIE and agreed self-hosted Code Security deployments remain responsible for their own backups, retention and restoration unless that work is assigned to Magdox. A later edition does not reduce an existing signed recovery obligation without the agreed amendment process.
8. Assurance and customer evidence
Magdox does not currently claim ISO 27001 certification, a SOC 2 report or regulatory approval for either product. A SOC 2 report is an attestation rather than a product certification. Framework grades inside FDIE describe assessed technical checks and do not certify Magdox or the customer's device.
Customers may request security questionnaires, relevant control evidence, recovery-test evidence and a platform SBOM where available. DPA audit rights are preserved. This document is not evidence of a completed independent audit.
9. Customer and support responsibilities
Customers configure membership, approved analysis inputs, recipients, data retention and integrations. Customer-operated installations additionally maintain host/runtime patching, storage capacity, TLS, local identity and firewall controls. Remote support is authorised and scoped; diagnostics should be minimised and redacted. Do not send raw firmware, credentials or secret material through the public website.
Dodo Payments handles online checkout directly; Magdox does not receive complete card details. Billing records and merchant-of-record processing are disclosed separately from analysis data.
10. Change management and contacts
Magdox may evolve controls without materially reducing overall protection during the contracted processing. Material contractual changes follow the applicable agreement, and updated provider notices follow the DPA. A later public edition does not silently replace an executed customer-specific schedule.
Security and vulnerability reports: security@magdox.io. Privacy and processing: privacy@magdox.io. Contract terms: legal@magdox.io.