Trust Centre

Privileged Access

How access to Arbiter infrastructure and to customer Edge appliances is controlled, logged, reviewed and (where appropriate) refused.

Operator access to Arbiter infrastructure

Arbiter's cloud control plane (arbiter-core, arbiter-radius, arbiter-ca, arbiter-web) is administered exclusively through portal.arbiter.ie, fronted by oauth2-proxy against Microsoft Entra ID. The Entra app registration enforces MFA via Conditional Access; SSH access to the underlying VMs is key-based against a single deploy key (arbiter_deploy) held by the engineering lead. There is no standing privileged user on the customer-data path.

Every state-changing action through the operator console writes anaudit_log row scoped to the affected tenant, with the actor field populated from the authenticated Entra identity (not a service account or placeholder). The audit log is append-only at the database trigger layer: even an operator with direct database access cannot modify or delete audit rows outside the per-tenant retention worker's controlled DELETE path.

The Edge appliance support shell

The Arbiter Edge appliance ships with a mechanism that lets Arbiter support engineers open an SSH session to the appliance over the existing mTLS tunnel, for diagnostics. We document this prominently because the mechanism shares an architectural shape with a backdoor and customers in regulated industries deserve to see it described clearly, not buried.

How it works

  • The Edge dials out to arbiter-radius:2083 over mutually-authenticated TLS. No inbound port is opened on the customer perimeter.
  • The tunnel carries four message types: RADIUS, DHCP, CoA and an SSH wrapper (MSG_SSH). The SSH wrapper streams bytes between the cloud-side operator's terminal and the appliance's local sshd onlocalhost:22.
  • Authentication uses a short-lived operator public key, pushed to the appliance over the heartbeat response every 60 seconds. Adding or removing a key from the cloud propagates within one heartbeat cycle.
  • Every session is recorded in the per-tenant Audit Log with operator email and timestamp. The customer can read their own audit trail through the tenant portal.
  • The tunnel certificate (and therefore the SSH path along with RADIUS, accounting and CoA) can be revoked by the customer at any time through Settings, Edge / RadSec, Revoke. Revocation takes effect in seconds.

Customer opt-out

Every tenant has a per-tenant toggle: Settings, Edge / RadSec, Arbiter Support Shell Access. When disabled, the Edge appliance silently drops every cloud-initiated SSH frame regardless of operator key. Disable propagates to every Edge for the tenant within one heartbeat cycle (typically under 60 seconds). RADIUS authentication, accounting, DHCP profiling and Change-of-Authorisation continue to work normally; only the Arbiter support path is closed.

With the toggle off, any future remote diagnostic from Arbiter requires the customer to grant hypervisor console access (or re-enable the toggle for the duration of the session). This is the recommended posture for NIS2 essential entities and customers whose threat model explicitly excludes vendor-initiated access. The toggle state is audit-logged on every flip with the operator who changed it.

Layered controls at a glance

  • Per-tenant toggle. Customer can refuse the support shell entirely. Default on, designed to be turned off without breaking the product.
  • No inbound exposure. Edge dials out. Customer firewall stays closed. Mechanism cannot be reached without a valid mTLS client cert that originates inside Arbiter's cloud.
  • Per-session audit log. Every shell session writes operator email, tenant, appliance device id and timestamp. Customer-readable.
  • Short-lived keys. Operator pubkey lives inauthorized_keys for as long as it is in the cloud-side allowlist. Removed key disappears from the Edge within 60 seconds.
  • One-click revocation. Revoke the Edge certificate to drop the tunnel entirely. SSH path dies with it.

DPA and sub-processor disclosure

The Edge support shell is disclosed in the Arbiter Data Processing Agreement template (see the DPA page in the Trust Centre) as part of Arbiter's processor role. Customers who disable the toggle should reflect that in their own internal sub-processor register: when the toggle is off, Arbiter no longer has technical access to the appliance and the processor disclosure narrows accordingly.

What this page does not cover

Endpoint authentication paths (EAP-TLS, MAB), the per-tenant PKI roots and the offline auth cache are documented separately on the Data in Transit and Data at Rest pages. CoA dispatch, accounting handling and DHCP profiling are end-user traffic, not privileged-access surfaces, and are described under the product documentation.

Last updated May 2026. For questions about this page, contact security@arbiter.ie.