How we protect your firmware, and what the engine is built on.
FDIE analyses some of the most sensitive assets your company owns. Here is exactly how we protect them, where the data lives, and what we do not yet claim.
Last updated September 30, 2026
At rest
AES-256
In transit
TLS 1.2+ / 1.3
Data region
India
Breach notice
Within 72 hours
SOC 2 Type II
Target Q3 2027
How your data is protected.
Encryption at rest and in transit
All traffic is encrypted via TLS, terminated at our edge and enforced end to end to origin. Database connections require TLS. Secrets are never hardcoded: they are issued dynamically, short-lived, and rotated through a dedicated secrets manager. Firmware and results are encrypted at rest with AES-256.
Multi-tenant data isolation
Every image, result and report is scoped to your organisation. The data model enforces org-level isolation at the database layer on every query, so your data is never visible to another tenant.
RBAC and audit logging
Role-based access controls who can upload, view or export. Every sensitive action, including uploads, exports, user and role changes, and authentication events, is recorded in an audit log available to your administrators.
MFA, email-code sign-in and SSO
Authenticator and email two-factor options, single-use email-code sign-in, and organization SSO through a configured OpenID Connect provider. Confirm identity-provider prerequisites during setup.
Hosted in India.
FDIE runs on Oracle Cloud Infrastructure in India, in Mumbai with disaster recovery in Hyderabad. Account data, audit logs, firmware images and analysis results are stored in India. If your data must stay outside India, deploy FDIE on-premises in your own environment. Provider and integration exceptions are listed in the DPA, including: transactional email (sign-in codes, alerts and emailed report files) through Zoho ZeptoMail in India; error traces without request bodies to Sentry in the US; and the sign-in IP address to a geolocation lookup for your audit log. Vulnerability lookups send component names and versions to public feeds, never firmware bytes.
Hosting region
India
OCI Mumbai. On-premise deployment for data that must stay outside India.
Disaster recovery
OCI Hyderabad
A second Indian region holds the standby and replicated storage.
Recovery objectives
Scoped in your Order Form
RPO, RTO and covered failure scenarios depend on the agreed deployment. See the Security Addendum for profile-specific limits.
On request
On-premise deployment
Scoped for your infrastructure in the Order Form
What FDIE is built on, and under which licences.
FDIE combines its own firmware analysis logic with maintained open-source libraries and isolated emulators. Analysis coverage depends on the image format, available evidence and enabled tools. A software bill of materials for FDIE is available on request.
| Component | Licence | Role in FDIE |
|---|---|---|
| In-house extraction engine | Proprietary | Unpacks firmware images and filesystems across 35 formats |
| FirmBin: disassembly and control-flow engine | Proprietary | Disassembles 19 CPU architectures and builds call graphs and reachability paths; decrypts vendor images where the key is published (D-Link SHRS today) |
| In-house binary parsing engine | Proprietary | Parses ELF and PE formats for component identification and CVE matching |
| QEMU (user-mode and system) | GPL-2.0 | Per-binary emulation across 15 architectures and full-system Linux boot, inside the disposable sandbox |
| Unicorn | GPL-2.0 | Fallback CPU emulator for MIPS, ARM and x86 when QEMU cannot run a binary |
| YARA | BSD-3-Clause | Content-based malware and implant rule matching on every extracted file |
| Supporting libraries | Open source, permissive | PDF rendering, zstd and lz4 decompression, cryptography primitives. Full list in the FDIE SBOM, on request |
Review the evidence behind each finding.
FDIE uses static analysis, pattern matching, vulnerability feeds and bounded runtime analysis. Reports distinguish component observations from vulnerability conclusions. Results depend on the engine version, feed freshness, configuration and analysis coverage; exported evidence supports review of those limits.
Findings with coverage limits
Analyst-owned decisions
Contextual checks help reduce noisy secret and cryptography matches. Uncertain results remain available for review. Emulation and fuzzing run in a disposable sandbox with no network egress; the sandbox is destroyed when the analysis ends.
You control how long we keep your data.
Firmware images and results are retained for as long as your account is active, or per your plan's configured retention window. You can request deletion of your images, analysis history and account data at any time. Details in the Privacy Policy.
Who we share data with.
A small number of sub-processors, each bound by data protection obligations no less protective than ours. The authoritative list, with vendor, purpose and processing region, is maintained in one place: our Data Processing Agreement, along with the 14-day advance notice and objection process for any new sub-processor.
Every sub-processor is named there. We do not keep that list behind a request form. Questions go to [email protected].
Our path to formal certification.
We do not hold formal security certifications today, and we will not claim we do. Our InfoSec Addendum describes the service baseline, deployment-dependent controls and current recovery limitations. Published control descriptions are separate from independent assurance.
Information Security Management System
We have not started the ISO 27001 programme. We are targeting certification in Q1 2028, after the SOC 2 Type II observation period, so the two audits can share the same control evidence rather than being run twice.
Target, not a commitment. This page is updated as the programme starts.
Independent audit of security, availability and confidentiality
We are targeting a SOC 2 Type II report in Q3 2027. This is an attestation report; the ISO 27001 certification programme follows. A Type II report covers a sustained observation period, so the target is the report date, not the start of the audit. Until the report exists, what we can share on request is our control documentation and completed security questionnaires. Both are self-attested, not independently audited; we say so on every copy. Contact us to request them.
Target, not a commitment. This page is updated as the audit progresses.
Evidence available today: request our control documentation and the arrangements for your deployment, including backup retention and recovery-test evidence where available. Planned controls, such as cross-region database backup copies, are identified in the InfoSec Addendum.
Found a security issue?
Email [email protected] with reproduction steps. We aim to acknowledge reports within 3 business days and triage them within 5. Scope, response targets and safe harbor are in the policy; credited researchers appear on the Hall of Fame.
Questions about our security architecture?
Talk to our team directly. We are happy to walk through the architecture with your security or procurement reviewers, and to answer a questionnaire in writing.
21-day free trial on the full platform. No card, no automatic conversion.