EasyRadius FAQ
General Questions
What is EasyRadius?
EasyRadius is an Azure-based SaaS RADIUS service that provides EAP-TLS certificate-based authentication for enterprise Wi-Fi and LAN. It is fully cloud-hosted, requires no on-premises infrastructure, and is available as a monthly or yearly subscription through the Azure Marketplace.
What authentication methods does EasyRadius support?
EasyRadius supports EAP-TLS, which uses client certificates for authentication. This provides strong, per-device authentication and eliminates the need for passwords or pre-shared keys.
How does EasyRadius integrate with EasyScep?
EasyScep is Just Software's SaaS Certificate Authority for Microsoft Intune. EasyScep issues client certificates to your managed devices, and EasyRadius validates those certificates when devices connect to your Wi-Fi or LAN. The two products work together out of the box — EasyRadius validates certificates from any CA with a reachable public OCSP responder, including EasyScep.
How do I subscribe to EasyRadius?
EasyRadius is available on the Azure Marketplace. You can subscribe directly from the Azure Portal. See our On-boarding Guide for step-by-step instructions.
How do I add RADIUS clients?
After completing the on-boarding wizard, log in to the administration portal at https://portal.just-software.com. Under Settings → Radius Clients, add a client entry for each network device (access point, switch, or VPN gateway) that will send authentication requests to EasyRadius. Each client requires the public IP address, network (CIDR) or hostname it connects from, and a shared secret. See RADIUS clients.
Which port does EasyRadius use?
Each instance has its own port, shown on the dashboard under Endpoints — it is not the standard 1812. With RADIUS over UDP, authentication uses that port and accounting the next one up; with RadSec, the same port over TCP. See Protocols and ports.
Does EasyRadius support RadSec?
Yes. Under Settings → System you choose whether your equipment may use RADIUS over UDP, RadSec (RADIUS over TLS), or both. RadSec encrypts the traffic between your equipment and EasyRadius; the equipment must present a certificate from a CA you have marked Allow for RadSec. See Protocols and ports.
What happens if one region is unavailable?
On plans with high availability, an instance has a primary and a secondary endpoint in two Azure regions. Your network equipment fails over between them, so configure both endpoints as RADIUS servers. If only the primary is configured, there is nothing to fail over to.
Security Questions
How does EasyRadius check certificate revocation? Does it support CRL?
EasyRadius checks revocation via OCSP. On every authentication it queries the OCSP responder named in the client certificate's Authority Information Access extension, and rejects the authentication if the certificate is revoked — or if the responder cannot be reached.
CRL checking is planned and is not available today. EasyRadius does not download or consult Certificate Revocation Lists. If your CA publishes only a CRL and has no OCSP responder, contact support@just-software.com before onboarding it.
See Certificate revocation checking for the details, including OCSP nonce support and which instances can change these settings.
Why doesn't EasyRadius support Entra ID password authentication?
This is a deliberate security decision. Authenticating WiFi users with Entra ID credentials (via EAP-PEAP/MSCHAPv2) introduces significant risks: the credentials pass through RADIUS infrastructure, MSCHAPv2 is vulnerable to offline cracking, WiFi cannot trigger MFA prompts, and users are exposed to evil twin credential harvesting attacks. EAP-TLS with device certificates avoids all of these problems — no user credentials are ever transmitted, mutual authentication prevents rogue access points, and devices prove they are enrolled and managed rather than just that someone knows a password.
See Why EasyRadius Uses Certificate-Based Authentication for the full technical and architectural explanation.
Can I use passkeys for Wi-Fi / 802.1X?
Not yet. Using passkeys on a network requires EAP-FIDO, which is still an IETF Internet-Draft (draft-ietf-emu-eap-fido) and has not been published as a standard. No major operating system ships an EAP-FIDO supplicant today, so devices cannot use it to connect.
Today we recommend EAP-TLS with device certificates issued by EasyScep or Intune. It is already phishing-resistant and passwordless: no credential is typed or transmitted, and the device proves its identity with a certificate. We are tracking the EAP-FIDO draft and will look at supporting it once operating systems do.
Am I affected by the AirSnitch WiFi vulnerability?
AirSnitch (disclosed February 25, 2026, NDSS Symposium) is a research framework that bypasses WiFi client isolation across virtually all tested access points and devices — including enterprise networks.
EasyRadius customers using EAP-TLS are significantly less exposed than password-based deployments, but not fully immune:
-
Protected: The most dangerous enterprise attack — intercepting RADIUS traffic, brute-forcing the shared secret, and deploying rogue infrastructure to steal credentials — does not work against EAP-TLS. Client devices verify the server's certificate before authenticating, so a rogue RADIUS server cannot impersonate your legitimate infrastructure. There are also no passwords to steal from intercepted EAP-TLS exchanges.
-
Not protected: The underlying client isolation bypass (MitM positioning between connected clients) affects all WiFi networks regardless of authentication method.
See the full AirSnitch impact assessment and mitigation guide for detailed recommendations.
EAP-TLS Authentication Troubleshooting
Windows Devices
Common Issues
- Certificate not found in personal store
- Wrong certificate selected for authentication
- Network adapter configuration problems
- RADIUS server connectivity issues
- TPM broken - try storing client certificate in software store
Troubleshooting Steps
-
Certificate Verification:
- Open certmgr.msc
- Check Personal store for client certificate
- Verify certificate chain is valid
- Confirm certificate has Client Authentication EKU
-
Network Configuration:
- Check WLAN/LAN profile settings
- Verify EAP-TLS settings
- Confirm RADIUS server details
- Test basic network connectivity
-
Event Viewer:
- Check System logs
- Review Network category events
- Look for EAP/RADIUS errors
iOS/iPadOS Devices
Common Issues
- Profile installation failures
- Certificate trust issues
- Wi-Fi profile misconfiguration
- Authentication timeouts
Troubleshooting Steps
-
Profile Verification:
- Check Settings > General > Profiles
- Verify certificate installation
- Confirm profile is trusted
- Review Wi-Fi configuration
-
Network Settings:
- Remove and re-add network profile
- Verify EAP-TLS settings
- Check server certificate validation
- Test with different networks
-
Diagnostics:
- Check Settings > Wi-Fi logs
- Review profile installation logs
- Test with Apple Configurator
Android Devices
Intune error
0x87d1fde8 (-2016281112) when the Wi-Fi profile fails to apply on Android Enterprise is almost always a certificate issue, not a RADIUS one: on a BYOD Work Profile the certificate must be a User certificate (not a Device certificate), and the UPN must be in the certificate's Subject Alternative Name (otherName OID 1.3.6.1.4.1.311.20.2.3), not just the CN. See the dedicated Android EAP-TLS troubleshooting guide for the full decision tree.
Common Issues
- Certificate storage location problems
- Network security type selection
- CA certificate trust issues
- EAP configuration errors
- BYOD Work Profile: Device certificate used instead of a User certificate (fails silently)
- BYOD Work Profile: UPN missing from the certificate SAN (present only in the CN)
Troubleshooting Steps
-
Certificate Management:
- Check Settings > Security > Certificates
- Verify certificate installation location
- Confirm certificate permissions
- Test with system/user certificates
-
Wi-Fi Settings:
- Use WPA2/WPA3-Enterprise
- Select EAP-TLS method
- Choose correct client certificate
- Verify server validation
-
Advanced Diagnostics:
- Enable Developer Options
- Check Wi-Fi verbose logging
- Review system logs
- Test with different Android versions
Network Equipment Configuration
Common Issues
- Wrong RADIUS server IP/port — the port is specific to your instance, not 1812
- Only the primary endpoint configured, so there is no failover
- The equipment's public address is not registered as a RADIUS client
- Incorrect shared secret
- Equipment that does not send Message-Authenticator (it fails with nothing in the log)
- Certificate validation failures
Troubleshooting Steps
-
RADIUS Configuration:
- Verify both endpoints' IP addresses and the port against the dashboard (Endpoints)
- Check that the protocol your equipment uses (RADIUS or RadSec) is enabled under Settings → System
- Check that the address your equipment connects from is listed under Settings → Radius Clients — the Logs page records requests from unknown clients, unless you block them at the network level
- Check shared secret matches
- If the equipment is old and nothing appears in the log, check Require Message-Authenticator under Settings → System
-
Certificate Settings:
- Review root CA trust
- Check the certificate's revocation status
- Verify the EasyRadius instance can reach your CA's OCSP responder (EasyRadius checks revocation via OCSP, not CRL)
-
Test with different certificates
-
Network Settings:
- Check VLAN configuration
- Verify authentication timeout
- Review logging settings
- Test basic connectivity
General Tips
-
Always verify:
- Certificate validity dates
- Certificate key usage flags
- Network connectivity
- RADIUS server status
-
Common solutions:
- Reinstall client certificate
- Reset network settings
- Clear cached credentials
- Update device OS
-
Getting Support:
- Collect relevant logs
- Document exact error messages
- Note device details
- Contact support@just-software.com