How we protect your firmware
Before you upload a firmware image, you need to know who can see it and what happens to it. Two-step sign-in for everyone, each organisation kept apart in the database, and an audit log the app cannot change.
Who can see your firmware, and what happens to it
Only your people get in
Two steps for every account, on every way in.
- An authenticator code after a password, Google Workspace, Microsoft 365 or single sign-on
- Passwords of 12 characters or more, stored as Argon2id hashes
- Repeated failed attempts lock sign-in for 30 minutes
No other customer sees your data
Each organisation sees only its own data.
- Row level security on every customer table
- Random UUIDs for every public id
- No ids or data in page addresses
Your tokens and keys stay sealed
What you connect is sealed and never shown again.
- TLS on every connection and managed keys at rest, rotated automatically
- Tokens and keys sealed with envelope encryption
- Uploads go straight to storage through a size-locked link
Your firmware stays contained
Analysed in isolated jobs that cannot reach the internet.
- Each analysis on a fresh machine with no route to the internet
- Archive bombs refused and links kept inside the tree
- Emulation, when your plan includes it, with the firmware's network refused
AI only if you turn it on
Off until your admin connects a provider.
- Only the masked snippets a task needs are sent
- Every output labelled with its model
- We never train a model on your data
Every action on record
Every sign-in, change and decision is recorded.
- Person, action, target, time and country
- Append only, each row chained by SHA-256
- Export as CSV from Settings
The measures in full
The technical and organisational measures we maintain for every organisation. They form Annex C of our Data Processing Agreement.
Encryption and secrets
Encrypted in transit and at rest, with separate keys for each kind of data.
- Every connection to the service uses TLS 1.2 or higher, with HTTP Strict Transport Security. Connections between the content delivery network and the application, and between the application and its database, are encrypted too, and the database refuses unencrypted connections.
- The database, file storage, application logs and the account audit trail are encrypted at rest with keys held in AWS Key Management Service, rotated every year.
- Credentials the service stores for you (code host tokens, AI provider keys, webhook signing secrets, single sign-on client secrets and two-step sign-in secrets) are sealed again with AES-256-GCM under data keys kept for each organisation, themselves protected by a key in AWS Key Management Service. They are never shown again after they are saved, beyond their last characters.
- Passwords are stored only as Argon2id hashes. CI tokens, SCIM tokens, MCP keys and recovery codes are stored only as hashes.
- Production secrets live only in AWS Secrets Manager; none is written to a file, an image or source code, and none is used outside production.
- Separate keys protect stored files, the database, secrets and logs, so access to one kind of data does not open another.
Sign-in, access and isolation
Two steps for every account, organisations kept apart by the database, every change on record.
- Every user signs in with two-step verification (an authenticator app, with single-use recovery codes). Organisations can also allow sign-in with Google Workspace and Microsoft 365, and your owners and admins can connect your own identity provider for single sign-on (OpenID Connect or SAML 2.0) after verifying your email domains, provision people with SCIM and require single sign-on, while your owners keep a password and two-step code in case the identity provider fails.
- Five failed sign-in attempts (twenty from a network the person has signed in from before) lock further attempts for 30 minutes, keyed to the account and to a keyed hash of the network. Sessions end after the idle period your organisation sets (30 minutes by default), and sensitive actions, such as deleting data, ask for a fresh two-step code.
- Each organisation's data is separated in the database by row level security, enforced for every query including the database owner's, in addition to the application's own checks.
- Four roles (owner, admin, analyst, viewer) limit what each person can do; accepting a risk needs a second person.
- Every change made in an organisation is written to an append-only audit log in which each event is chained to the one before it by a hash, so that a removed or altered event shows. The log is kept for two years, unless your owners or admins choose between one and ten years.
- Our staff reach production systems only with individual, multi-factor protected accounts and the least privilege their task needs. Access is reviewed and removed when it is no longer needed.
Application protection
A web application firewall in front, strict checks on every request, no servers to sign in to.
- A web application firewall with managed rules for known bad inputs and common attacks, a list of addresses with a bad reputation and a limit on requests from one address protects the service.
- Every request is checked for its origin, its session and, for changes, a per-session token against cross-site request forgery. Requests carry their data in the request body, never in the address, and bodies are size-limited and strictly checked.
- Pages are served with a restrictive content security policy and cannot be framed by other sites.
- The service runs in containers on AWS Fargate, in private networks: there are no servers to sign in to and no SSH or remote desktop access. Container images are scanned for known vulnerabilities when they are pushed and rebuilt when security updates are released.
- Requests the service makes to addresses you give it (webhooks, your own AI endpoint, code hosts) are checked so that they cannot reach private or internal networks.
- Uploads are written directly to storage through links that allow only the declared file and size, and expire.
- The password reset and invitation forms, and sign-in after two failed attempts, use Cloudflare Turnstile to tell people from automated traffic; our servers confirm each check with Cloudflare before going further.
How firmware and code are analysed
Isolated jobs with no internet access; firmware runs only under emulation, when your plan includes it.
- Firmware images and source code are analysed in isolated jobs, each in its own container, in a network with no route to the internet. A job holds no cloud credentials. It gets three links that work for that job alone, to read its job file, read its own input and write its own result, each expiring with the job's time limit of at most three hours. It can reach nothing else in storage.
- The analysis reads, unpacks and examines files without running them. When an organisation's plan includes runtime evidence, programs from the image are also run under emulation, in a separate isolated job of the same kind, with the firmware's own network access refused. Unpacking keeps strict limits on size, file count, compression ratio and nesting, refuses links that point outside the work folder and keeps every file inside the job's own folder.
- Source code is deleted when its scan ends, unless your owners or admins choose to keep it for a period, at most ten years. Findings keep only short excerpts, with secrets masked.
- While you have an AI provider connected, the Service uses it within your caps, on its own for each analysis and when a person asks, and sends it what the engine found: findings with masked evidence (at most 40 lines each) and matched vulnerabilities with their components and versions; for firmware tasks also masked excerpts of the decompiled functions concerned (at most 60 lines each), the strings and file paths they use, and the programs and network services in the image. Secrets, password hashes and email addresses are masked and no whole file is ever sent. It goes to the provider you connected, under your own account. The data travels in a marked block that the model is told never to treat as instructions, and every answer is checked against the expected form before it is stored. MAGDOX never uses your data, including your code, firmware, findings, files and personal data, to train any artificial intelligence or machine-learning model. If your organisation connects its own AI provider, that provider's handling of the data it receives, including whether it trains on it, is governed by your organisation's own agreement with it.