You should only expect to see this rate in very large organizations first thing in the morning as staff arrive as well as possibly early afternoon as staff return from lunch. Universities often see this level of load as students place their devices to sleep and wake them up moving between lectures.

In practice servicing more than 10,000 rps per core is relatively easy for a RADIUS server, but slow downs occur when:

RAM primarily used to support running the Azure Monitor Agent and providing more than 2GiB of RAM is unnecessary.

More than a single vCPU is useful so that OS updates or Azure Monitor Agent events do not impact the actual RADIUS handling components running on the server. Running a single vCPU is likely to cause latency issues if you have a large number of requests.

On a related note, where possible you should use Ephemeral OS disks as they are cheaper and faster otherwise at least a Standard SSD is recommended.

This typically is a problem for EAP-(T)TLS authentications as for large certificate chains only about one thousand (1000) bytes can be transmitted in a single round trip; 2kiB to 5kiB in total is not uncommon which for a RTT of 100ms (‘width’ of the US or EU) immediately adds at 200 milliseconds (one fifth of a second) to the authentication time experienced by your users and this is before delays due to database or Microsoft Entra ID authentications are taking into consideration. This will only get work as the downside of solutions to Post-Quantum (PQ) attacks are large certificate chains, as much as three (3) to five (5) times larger.

Using TLS session resumption masks this latency problem (except for the initial TLS handshake) and so is always recommended.

Best is to make sure you pick a region that is always close to you.

This is not a technical limitation of the service as internally we deploy to on-premise equipment during development, but it is done this way so to protect our Intellectual Property.

If this is a blocker for you, then do please contact us to describe why and maybe we can work something out.

This is useful if you already have a RADIUS service you are happy with but are seeking a solution to allow visitor access without igniting your bank account on any per-user/device licensing arrangements you may use there.

The typical solution here would be to deploy something like FreeRADIUS to handle this for you, which requires either in-house expertise or the use of a consultant.

The disadvantage is cold starts that manifest as slow API calls that make the UI feel slow.

Unfortunately Microsoft do not expose controls to set our own idle time thresholds and so the only solution to this would be to use always ready instances which add a minimum of $5/month to your Azure bill.

As the API is expected to be only occasionally used, for some only once when you configure your deployment, we decided to lean towards cost savings.

The resources are placed in a resource group with a read-only deny assignment blocking access to most changes. Some permissions have been allowed, including:

It is recommended you use RadSec where possible for reasons of security as well as user privacy.

Your deployment is your own and private to you.

We have no visibility in how you use it, other than if you choose to use a 'co-administrator' plan which is not the default and not recommended for most users.

We do received lifecycle notifications described in our privacy policy.

For non-Intranet marked devices, typically upstream federation proxies, your own users roaming will have the User-Name attribute removed from any Access-Accept responses and instead a Chargeable-User-Identity (CUI) in its place. This identity is fixed for all devices the user uses but is rotated once a week. The purpose of the CUI is to aid abuse reports so an operator of a remote site can communicate to you that a particular user has caused them problems and to have you take action or alternatively choose to block that CUI to deny local service.