How AssetTrove protects your data
Where your data is stored, how it's kept separate from other customers, and the other security measures behind AssetTrove.
Asset registers hold sensitive information: names, serial numbers, locations and contract prices. AssetTrove was designed from the start to keep that information safe.
Your data stays in the EU
Your organisation's data is stored in the EU, in Paris, France.
Your data is separated from other customers by the database itself
Many products keep customers apart only in their application code, where one bug can expose another customer's data. AssetTrove also enforces the separation in the database (PostgreSQL row-level security). Every query is limited to your organisation, even if the code above it has a mistake.
We also test this on every change: an automated test calls every part of the API as one organisation using another organisation's IDs, and expects not found every time. AssetTrove answers not found rather than forbidden, so it doesn't even reveal whether something exists.
Encryption
| What | How it's protected |
|---|---|
| Data in transit | TLS 1.2 or newer everywhere, with HSTS |
| Data at rest | Encrypted disks and storage (AES-256) |
| Connector secrets (for example your Intune client secret) | Encrypted separately for each organisation, never shown again after you save them and never written to logs |
| API keys and SCIM tokens | Never stored at all, only a keyed hash, so even we can't read them |
A trustworthy history
Every change is written to an audit log in the same step as the change itself, so a change can't happen without being recorded. The log is chained with cryptographic hashes and anchored hourly in write-once storage that can't be deleted, so any tampering can be detected.
Least-privilege access
Roles can be limited to a single location or cost centre, employees only see their own devices and licences, and API keys can never be more powerful than the person who created them.
Other safeguards
- Every request is validated and size-limited.
- Webhooks can only be sent to public HTTPS addresses, checked again at the moment of delivery.
- Spreadsheet exports are protected against formula injection.
- An external penetration test, including cross-customer attacks, is planned before general availability.