Data in transit
How Arbiter protects customer data while it is moving between your network, your administrators and our platform. For information on how data is protected while stored, see Data at Rest. 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.
Arbiter encrypts every customer-data RADIUS exchange in transit using mutually authenticated TLS. The single supported transport is RadSec (RFC 6614), terminated by an on-premises Arbiter Edge appliance and carried to EU-operated cloud infrastructure. Arbiter does not expose a public UDP RADIUS endpoint. Administrative access uses TLS with identity delegated to the customer's own identity provider; Arbiter does not store passwords for federated users.
How customer-data traffic flows
A typical authentication traverses four segments. Three of them are encrypted across public-network boundaries with modern TLS. The fourth is a switched LAN inside the customer's own physical perimeter.
Every Arbiter deployment uses the Arbiter Edge appliance, a lightweight virtual appliance installed on the customer LAN. Network access devices speak standard RADIUS to the Edge over the local network. The Edge then carries every protocol message (authentication, accounting and change-of-authorisation) to the Arbiter cloud inside a single mutually authenticated TLS tunnel using RadSec (RFC 6614). The tunnel is established by the Edge as an outbound connection. The cloud does not accept RADIUS over any other transport.
Tenant identification on the cloud side is by client certificate Common Name. Source IP is recorded for telemetry but is never used as an identifier. A customer moving between sites or operating behind NAT continues to authenticate correctly with no configuration changes.
The Edge appliance is the architectural keystone. Arbiter's customer base is predominantly small and mid-sized organisations whose networks have grown organically: a mix of switches, access points and controllers from multiple vendors and multiple generations. RadSec support across that estate is uneven; many devices, including current-generation kit from major vendors, still cannot speak RadSec natively. By terminating RadSec on the customer LAN, the Edge absorbs that variability. The result is an encrypted-in-transit posture that is universal across the deployment, rather than contingent on the firmware of each individual device.
RadSec and the Edge appliance are available on every Arbiter plan. Arbiter does not gate security features by tier.
Encryption
RadSec transport
RadSec carries every RADIUS message inside a single mutually authenticated TLS tunnel between the Edge appliance and the Arbiter cloud. Connections use modern TLS with forward-secret key exchange and AEAD cipher suites. Tenant authentication uses modern ECDSA certificates issued by the Arbiter PKI, with automated rotation and revocation support.
No public UDP RADIUS
Arbiter does not operate a public UDP RADIUS listener. RADIUS-over-UDP is permitted only on the customer LAN between network access devices and the Arbiter Edge appliance, where the traffic stays inside the customer's own physical perimeter. The Edge then carries every message onwards inside the RadSec tunnel.
We previously offered a public UDP listener as a compatibility on-ramp. We retired it because RADIUS-over-UDP leaks attributes in cleartext (usernames, MAC addresses, NAS-IPs, Called-Station-Id, VLAN names), exposes an injectable attack surface (the class of which CVE-2024-3596 / BlastRADIUS is one example) and offers no clean inbound path for RFC 5176 change-of-authorisation without holes in the customer firewall. The full rationale is in the dev-log: Why we dropped public UDP RADIUS and went pure RadSec.
On the LAN segment between switches and the Edge, the platform still enforces Message-Authenticator (RFC 3579) on every Access-Request, generates 32-character UUID-strength shared secrets that customers can rotate but not weaken and rejects standalone PAP outside an EAP-TTLS or PEAP tunnel. These are belt-and-braces measures: the surrounding physical perimeter is already the primary control.
Change-of-authorisation
When a session needs to be disconnected, an endpoint moved to a quarantine VLAN or a new ACL applied, the change is delivered through the same Edge-initiated tunnel that carried the original authentication. Arbiter routes the change-of-authorisation back to the listener that terminated the source tunnel. This eliminates the inbound-firewall problem that traditional cloud RADIUS imposes on customers: no NAT pinhole, no static public IP and no firewall rule at the customer edge are required.
Administrative interfaces
Arbiter operates two distinct administrative surfaces. Both are reachable only over HTTPS, with TLS 1.2 or higher and TLS 1.3 preferred. HSTS is configured and the production domains are eligible for browser preload-list inclusion. Public TLS certificates are issued via ACME with automated renewal.
Inter-service traffic within the Arbiter cloud
Service-to-service traffic inside the Arbiter cloud uses TLS with forward-secret key exchange and AEAD cipher suites. Mutual TLS is applied on tenant-bearing paths. Database connections use TLS to a connection pool, with PostgreSQL behind it. Service credentials are rotated on a documented schedule.
Identity
Tenant portal
The surface used by customer administrators to manage their own deployment. Tenant portal authentication supports sign-in with Microsoft Entra ID, sign-in with Google Workspace and Arbiter-managed passwordless authentication using a one-time email link paired with a WebAuthn passkey. Customers operating their own SAML 2.0, OpenID Connect or SCIM 2.0 identity infrastructure can connect Arbiter to it.
Authentication and authorisation are independent. The customer's identity provider establishes who a verified user is. Arbiter determines, separately, whether that verified user has access to a given tenant and at what role. Tenant administrators invite users by email address and assign one of three roles (Owner, Admin or Read-only) at the point of invitation. A user must exist in both their identity provider and Arbiter's tenant user records; presence in the identity provider alone does not grant access.
For users authenticating through a federated identity provider, Arbiter does not store, hash or otherwise possess any password. The credential never reaches Arbiter; only a signed assertion of identity does. The customer's existing authentication policies (multi-factor authentication, conditional access and session lifetime) apply automatically to Arbiter login. Revoking a user in the customer's identity provider revokes future Arbiter authentication subject to active-session and token-expiry boundaries. For customers using Arbiter's passwordless option, the WebAuthn passkey is bound to the user's device and Arbiter retains only the public key.
Arbiter staff dashboard
The internal surface used by Arbiter personnel to operate the platform. Authentication is delegated exclusively to Arbiter's corporate Microsoft Entra ID tenant. Arbiter holds no internal staff password, issues no out-of-band credential and operates no parallel identity store. Conditional access, multi-factor authentication, named-location and session-lifetime policies are enforced centrally. Revocation of an Arbiter employee's Entra account revokes future authentication subject to active-session and token-expiry boundaries.
Directory traffic
End-user authentication against an on-premises directory (whether Active Directory or LDAP) is handled by the Arbiter Edge. The Edge holds the directory binding; the Arbiter cloud never possesses the customer's directory credentials. Where a credential exchange is unavoidable, for example a PAP request from a legacy VPN concentrator, the credential is carried inside the EAP tunnel or the RadSec tunnel and validated against the directory by the Edge over LDAPS or signed Kerberos. It does not traverse the public internet in any form.
Where customer-data traffic is processed
Data residency is most often discussed as an at-rest property: which database is in which region. Arbiter extends the same principle to data in motion. A TLS-encrypted byte still leaks metadata such as source IP, timing, attribute names and certificate identifiers. If the encrypted byte traverses a CDN or zero-trust intermediary under a non-EU operator's control, that metadata may be processed by infrastructure subject to non-EU legal jurisdiction.
Arbiter does not control internet packet routing, submarine cable selection or transient carrier paths, and makes no claim to do so. What Arbiter does control is the domicile and operation of the components that handle customer-data traffic. Arbiter aims to ensure that customer-data traffic handled directly by Arbiter-controlled infrastructure is processed within the EEA wherever operationally feasible.
| Component | Operator | Region |
|---|---|---|
| RADIUS and RadSec listeners | Arbiter Ltd | EU |
| Application and database | Arbiter Ltd | EU |
| RadSec and client PKI | Arbiter Ltd | EU |
| Web Application Firewall | EU-domiciled provider | EU |
| Public TLS issuance | Let's Encrypt (ISRG) | Global ACME |
| Staff dashboard IdP | Microsoft Entra ID (Arbiter tenant) | Customer-controlled by Microsoft |
| Tenant portal IdP | Customer's chosen IdP, or Arbiter passwordless | Customer-controlled |
Cryptographic baseline
Arbiter selects modern, widely audited cryptographic primitives and rotates the material that protects them on a documented schedule.
| Channel | Protocol | Material and rotation |
|---|---|---|
| Edge to Cloud RadSec | Modern TLS with forward-secret key exchange and AEAD cipher suites; mutual authentication | Tenant client certificates issued by the Arbiter PKI; automated rotation and revocation support |
| Administrative HTTPS | TLS 1.2+ with TLS 1.3 preferred; HSTS configured | Public certificates via ACME with automated renewal |
| LAN-side RADIUS (switch/AP to Edge) | RFC 2865 over UDP, Message-Authenticator (RFC 3579) enforced | Per-tenant shared secret, 32-character UUID-strength minimum, customer-rotatable |
| Inter-service (cloud) | TLS with forward-secret key exchange and AEAD cipher suites; mTLS on tenant-bearing paths | Internal certificate authority with automated rotation |
| Database connections | TLS to connection pool; PostgreSQL behind the pool | Service credentials rotated on a documented schedule |
Algorithm choices are reviewed against current best-practice guidance from NIST, IETF and equivalent EU references (ENISA, BSI) at least annually and on disclosure of any cryptographic weakness affecting a primitive in use. Reviews and the resulting changes are managed under Arbiter's change management programme.
A more detailed cryptographic specification (including specific curves, cipher suites, certificate lifetimes and revocation mechanisms in operation) is available to customers and prospective customers under NDA in the Arbiter Security Whitepaper.
Independent verification
Arbiter's encryption-in-transit controls support the following SOC 2 Trust Services Criteria:
- CC6.1: Logical access security software, infrastructure and architectures, including the cryptographic protection of communications and the use of mutual authentication where the protocol supports it
- CC6.6: Logical access controls over communications between system components, including the protection of customer-data flows on public networks
- CC6.7: Restriction of the transmission, movement and removal of information to authorised users, including the EEA operation of customer-traffic processing infrastructure
- CC7.1: Detection and monitoring of new vulnerabilities, including the platform-enforced mitigations associated with CVE-2024-3596 (BlastRADIUS)
- CC7.2: System monitoring including for anomalies, including audit logging of transport mode, listener configuration and administrative actions
- CC8.1: Change management for the configuration of listeners, cryptographic primitives and identity controls
Supporting policies cover cryptographic control selection, certificate lifecycle, listener configuration and administrative access.
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:
- Hardware-backed RadSec keys for the Edge appliance, allowing tenant client certificate private keys to be held in a TPM or comparable secure element on customer hardware
- Phishing-resistant administrative authentication as the only supported option for the staff dashboard, retiring any non-WebAuthn fallback paths
These enhancements will be announced as they ship. We do not claim controls in advance of their delivery.
Last updated 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.