Support
A ForensicsGuard deployment runs on your hardware, inside your network, often with no route out of it. Support is built around that: it is conducted by correspondence, it does not depend on us having access to your deployment, and it never requires you to send us case material.
Getting help
There is one support address. What differs between the routes below is what the message should contain and how it will be handled once it arrives.
If you are running a pilot or an evaluation and something is not behaving as described, write to us directly. Include the detail listed further down this page — a request that arrives complete can usually be worked on immediately.
Commercial questions, procurement, documentation requests and anything that is not a fault report. Written contact is better for anything technical, because it leaves a record both sides can refer back to.
+974 7471 8495 · Doha, Qatar
Do not report a suspected vulnerability to the general support address. It should be handled as a security matter from the first message rather than after a support triage.
If you are not yet a customer and want to arrange an evaluation, the pilot and contact pages are the better starting points.
Preparing a request
A support request that arrives with the following can usually be acted on straight away. One that does not normally costs a round trip before anything happens, which in an isolated deployment can be a slow round trip.
Do not attach evidence, case exports, captures, reports, screenshots containing case content, or personal data of any kind to a support request. We do not need it, we should not hold it, and the platform is deliberately built so that no part of supporting you requires it.
If a fault can only be described by reference to something in a case, describe it — the shape of the problem, the field that is wrong, the exact wording the interface showed — rather than sending the material. Where that is genuinely not possible, say so, and we will agree an approach with you before anything is sent.
Common questions
These recur in almost every evaluation. Each answer links to the page that covers the mechanism in full.
Not for what it is for. Network observation, detection, Mobile Sensor collection, case work, correlation, reporting, evidence sealing and licence verification are all designed to run without one.
Connectivity adds software updates, updated indicator and network-intelligence datasets, and support. Each of those can also be delivered out of band, so a deployment in an isolated network is a supported configuration rather than a degraded one. The architecture page sets out the dependency split in full.
Out of band. A release is delivered as files you carry in, rather than as something the deployment reaches out to fetch, and it arrives with a signed integrity manifest describing the components it contains.
The appliance verifies that manifest against a public key it already holds, so the whole check happens inside your environment. Manifests carry a monotonic sequence number, which is how a deployment refuses an older release presented to it as a newer one. See Security & Trust for the mechanism and verification & updates for the published keys.
Exactly as it does if it is. A licence is signed by us and names the Guardian ID of one specific appliance; the appliance verifies that signature against a public key it already holds and checks that the licence names its own identity.
There is no activation server, no online check and no requirement to remain reachable. The entire exchange can be conducted by moving files, which is what an isolated deployment actually needs. A licence issued for one appliance does not operate another.
That the appliance could not establish what it should be verifying itself against — most commonly because the build it is running is not anchored to a signed release. There is nothing for it to check, so it says so.
It is not the same as a failed verification, and it is deliberate: the platform is built to report that it does not know rather than to claim an assurance it cannot support. Treat it as a state to resolve rather than as evidence of tampering, and raise it with us with the component, the software version shown in the interface and the exact wording of the state.
No. The platform has no mechanism by which case material is transmitted to us as part of normal operation. Captures, cases and exports are written to storage inside appliances and stations you operate, and support is conducted by correspondence rather than by access to your deployment.
This is the same reason a support request should never contain evidence. The right answer to "can you look at our case data" is that we should not be in a position to. Evidence ownership is described on the architecture page.
Through the route described on the security page, not through general support. Please do not send vulnerability detail to the support address.
We would rather hear about a weakness from you than discover it in a customer deployment, and reports are handled as a security matter from the first message.
If you are not yet running ForensicsGuard, a pilot answers most of the questions above against your own network rather than in the abstract.