Data at rest
How Arbiter protects customer data while it is stored. For information on how data is protected while in motion, see Data in Transit. For information on how administrative access is controlled, see Privileged Access. For a full list of service providers used to deliver Arbiter, see Sub-processors.
Where customer data lives
Arbiter stores all customer operational data (endpoints, policies, authentication logs and tenant configuration) on a replicated PostgreSQL cluster running on dedicated infrastructure in Hetzner's German data centres. Customer operational data is hosted and processed within EU-operated infrastructure and is not replicated to hosting providers outside the EU.
For the storage and processing of customer operational data, Arbiter does not use Amazon Web Services, Microsoft Azure, Google Cloud or any other hyperscale cloud provider. This is a deliberate architectural choice designed to keep customer operational data on EU-operated infrastructure and to support our customers' obligations under GDPR and the Schrems II judgement.
Arbiter uses a small number of independent service providers for narrowly scoped supporting functions, for example payment processing and transactional email. These providers act as independent controllers under their own data protection commitments and do not store or process customer operational data. A current list is published on our data protection page.
Encryption
Database storage
The PostgreSQL data directory resides on a LUKS-encrypted volume using AES-256 in XTS mode, a widely used standard for full-disk encryption. Encryption is applied at the block layer, transparent to the database, and is intended to protect against physical disk theft, snapshot exfiltration and unauthorised access to the underlying storage by infrastructure providers.
Backups
Database backups are encrypted independently of the source volume before being written to backup storage. Backup encryption uses age with curve25519 recipient keys; the corresponding identity key is held offline by Arbiter Ltd in physically secured locations within the EU.
Backups are encrypted before they leave the source host. This is intended to protect against backup theft scenarios where the source volume's encryption is not in scope.
Sensitive credentials
A specific category of data is treated with elevated protection in addition to the underlying volume encryption:
- RADIUS shared secrets
- Certificate private keys (per-tenant PKI roots and server-leaf keys)
- Third-party API credentials for MDM integrations
- SIEM target secrets
- SFTP export credentials
- Webhook signing secrets
Certificate private keys use a per-tenant data encryption key (DEK) wrapped by a master key held on a separate host from the database. Neither host alone can recover a tenant's key material: a database read yields ciphertext and a wrapped DEK; the unwrapping master key lives on an isolated host reachable only over mutually-authenticated TLS, and every unwrap is audit-logged by tenant id and requesting client identity.
RADIUS shared secrets, third-party API credentials, SIEM target secrets, SFTP export credentials and webhook signing secrets are encrypted under an application-layer master key held outside the database. Connect-device activation tokens are additionally one-way hashed with Argon2id, so the original token cannot be recovered from the database even with the master key.
An actor with read access to the Arbiter database alone cannot recover any of these credentials.
Key management
Encryption keys are managed by Arbiter Ltd. Specifically:
- Volume encryption keys are held by Arbiter operations staff and used to unlock the database volume at boot. Recovery keys are held offline in two geographically separated EU locations.
- Backup encryption keys are held offline as described above. They are not present on production systems.
- Application-layer master keys are stored separately from the database in a restricted-access location accessible only to the application process. For certificate private keys, an additional layer of per-tenant data encryption keys is used: the per-tenant DEK is wrapped by the master key, and the master key sits on a host distinct from the database. Other sensitive credentials are encrypted directly under the application-layer master key.
Encryption keys used to protect customer operational data are owned and controlled by Arbiter Ltd within the EU.
What Arbiter can and cannot see
We believe transparency on this point is more valuable than vague claims of "zero knowledge." The honest position:
| Data category | Arbiter platform access | Arbiter staff access |
|---|---|---|
| Endpoints, policies, authentication logs | Required for service operation | Restricted by role; logged |
| Tenant configuration | Required for service operation | Restricted by role; logged |
| RADIUS shared secrets, API keys, certificate private keys | Decrypted only at point of use | Not directly accessible; reveal events are logged |
| Backup data | Not accessible from the platform | Requires offline keys held by Arbiter Ltd |
Operational data must be readable to the Arbiter platform in order to authenticate your devices and enforce your policies. This is true of every NAC service. What is not required is broad staff access to that data: all administrative access is role-based, logged and reviewed.
Independent verification
Arbiter's encryption-at-rest controls support the following SOC 2 Trust Services Criteria:
- CC6.1: Logical and physical access controls, including the use of encryption to protect data at rest
- CC6.3: Segregation of credentials and sensitive data from general operational data
- CC6.7: Restriction of the transmission, movement and removal of information
- CC7.5: Recovery of encrypted backups as part of resilience and recovery
- CC8.1: Change management for cryptographic procedures, including key rotation
Supporting policies cover key management, cryptographic control selection, backup integrity and media handling.
Arbiter Ltd is pursuing SOC 2 Type II attestation. Audit reports will be made available under NDA upon request once attestation is complete.
Future enhancements
The following are on Arbiter's published security roadmap:
- Customer-managed keys for selected sensitive fields, allowing larger and regulated customers to retain ultimate control of their own encryption keys
- Hardware security module (HSM) backing for the application-layer master key
These enhancements will be announced as they ship. We do not claim controls in advance of their delivery.
Last updated 22 May 2026. For questions about this page, contact security@arbiter.ie.
Questions about Arbiter's security posture?
Contact our security team directly or start a trial to evaluate Arbiter in your own environment.