dedicated radius · cloud-hosted · for ISPs

Managed RADIUS that does more than Accept or Reject.

Point your BNGs at AuthMesh and we run the authentication, accounting and subscriber telemetry, turning every accounting packet into dashboards, anomalies and alerts. No FreeRADIUS to run, patch or scale.

Book a demo > Trace the packet flow

2M/s: requests tested, no added latency
0: RADIUS servers to run or patch
1:1: isolated stack per account

radius://ingress · proxy-agent · TLS ● live

→ Access-Request id=0x7a2f · 41 AVPs

User-Name = "sub-104822@isp"

NAS-IP-Address = 100.64.0.3

NAS-Port-Id = "eth 0/2/1:1001"

Agent-Circuit-Id = "OLT-3/PON-0/1/2"

Framed-Protocol = PPP

← Access-Accept 2.4 ms

Framed-IP-Address = 100.83.14.22

Session-Timeout = 86400

Mikrotik-Rate-Limit = 500M/500M

◈ Accounting-Start · session 9f2c34a1

auth accounting reject streaming → telemetry

Acct-Session-Id/NAS-Port-Type = Ethernet/Calling-Station-Id/Acct-Input-Octets/Agent-Remote-Id/Framed-IPv6-Prefix/Acct-Status-Type = Interim-Update/Called-Station-Id/Delegated-IPv6-Prefix/NAS-Identifier/Acct-Output-Octets/Event-Timestamp/Tunnel-Client-Endpoint/Acct-Terminate-Cause/Acct-Session-Id/NAS-Port-Type = Ethernet/Calling-Station-Id/Acct-Input-Octets/Agent-Remote-Id/Framed-IPv6-Prefix/Acct-Status-Type = Interim-Update/Called-Station-Id/Delegated-IPv6-Prefix/NAS-Identifier/Acct-Output-Octets/Event-Timestamp/Tunnel-Client-Endpoint/Acct-Terminate-Cause/

signal path

Trace a request from your BNG to an alert

You send RADIUS. Everything after ingress (auth, accounting, storage, correlation and alerting) is run and scaled by us. Here's the whole path.

01

clients

BNGs, NAS & other RADIUS clients on your network
02

proxy-agent

Lightweight process wraps the stream in TLS
03

ingress

Data engine terminates & validates the stream
04

radius

Managed auth & accounting, fully handled
05

store

Isolated auth & telemetry stores, per account
06

act

Insights, alerts, API, Slack / Teams / webhooks

alt path: skip stage 02 and send RADIUS UDP straight to ingress over a private link (AWS Direct Connect / Azure ExpressRoute).

topology.svg reference deployment

recommended

Proxy agent

A small process on a VM, server or container you already run. Devices point at it; it encrypts to TLS before it leaves your network. Run two, point your BNGs at both RADIUS IPs, and it's redundant.

✓ encrypted over the public internet

✓ no new hardware

✓ redundant, no shared state

direct

Private connection

Send RADIUS UDP straight to the ingress engine. UDP is unencrypted, so we only advise it over a private link (Direct Connect or ExpressRoute) via private peering.

· no agent to deploy

· private peering on AWS / Azure

· best for high-throughput regional sites

platform

Everything you need, none of the RADIUS to run

AuthMesh hides the parts of RADIUS nobody wants to own, so your team works with subscribers and outcomes, not attribute dictionaries and failover config.

Provision subscribers, not attributes

Create a real ISP subscriber from the dashboard or the API. AuthMesh materialises the RADIUS profile (users, attributes and policy) so nobody on your team hand-writes a dictionary again.

POST api.authmesh.co.uk/v1/subscribers

{
  "username": "sub-104822@isp",
  "plan": "fibre-500",
  "auth": "pppoe"
}

201 subscriber provisioned ready to authenticate

Fully-managed RADIUS

Auth and accounting run, patched and scaled by us. No FreeRADIUS to babysit.

Isolated per account

Dedicated auth, accounting and database instances. No noisy neighbours, no shared blast radius.

2M/s

tested throughput

Spikes in auth or accounting scale automatically, with no added latency at two million requests a second.

TLS proxy agent

Encrypted transport from a VM or container you already run. Deploy it redundantly.

OpenAPI automation

A documented API to provision subscribers and wire AuthMesh into your OSS/BSS and pipelines.

insights

The packets that authenticate a subscriber also tell you the network is breaking

Most RADIUS answers yes or no. AuthMesh reads the whole accounting stream and turns it into detections your NOC actually wants, then fires them where you already work. Because we run your auth, we see every request in full, not a sampled copy from a tap. A few we run out of the box:

critical → slack

rule · acct_octets(circuit_id: OLT-3/PON-0/1) == 0

12 subscribers went quiet together

Correlated by circuit ID down to the OLT and PON port. One likely PON outage, not twelve separate tickets.

warning → teams

rule · reconnects(subscriber) > 6 within 5m

A line reconnecting every few minutes

Flapping sessions surface on their own, so you see the unstable line before the customer calls it in.

anomaly → webhook

rule · output_rate < p50(nas_port peers)

A subscriber running far below its peers

Low-bandwidth outliers flagged against everyone else on the same BNG port, using the same accounting data.

routing → any

rule · on match: notify(slack, teams, webhook)

Straight into your workflow

Every detection can raise an alert into Slack, Microsoft Teams or an HTTP webhook. No new console to watch.

These are the kind of features we build toward: the same NAS-Port and circuit-ID data your BNGs already emit, put to work. Need a detection specific to your topology? We'll build it with you.

outputs

Fits the way you already operate

Push events and alerts out, or pull everything through the API into your own systems.

Slack

Teams

Webhooks

OpenAPI

Dashboard

Private link

Book a demo and we'll trace a topology for your ISP, wire up the proxy agent, and share pricing. You keep running the network; we'll run the RADIUS.

Book a demo View pricing

✓ fully managed, per-account isolated · ✓ support on every plan, 24/7 on Premium · ✓ updates & features included