FortiAuthenticator includes a built-in RADIUS AAA server that authenticates users and devices for FortiGate, switches, wireless, VPN, and other network-access clients. Current FortiAuthenticator architecture separates RADIUS clients from RADIUS policies: every network access server (NAS) that sends requests must be registered as a client, and policies define the authentication logic applied to those clients. Current 8.0 releases also support features such as client groups, EAP methods, RADIUS accounting, Disconnect messages, Message-Authenticator requirements, HA clustering, and geographically distributed load-balancing.
Within Fortinet Security Operations, RADIUS should be designed as an identity service with network, certificate, availability, logging, and policy dependencies—not as a shared secret plus UDP port.
Existing material on RADIUS and 802.1X authentication provides the protocol foundation.
Every NAS must be represented as a RADIUS client
FortiAuthenticator will not accept authentication requests from a device until it is configured as an authentication client and associated with policy logic.
Use stable management/source IPs and avoid NAT between NAS and FortiAuthenticator where possible; unexpected source IP is a common cause of RADIUS rejection.
Group clients only when they truly share the same trust and secret strategy.
Shared secrets should be unique and rotated
Each RADIUS client uses a pre-shared secret to authenticate messages.
Use high-entropy secrets stored in a password/secret-management system rather than one organization-wide secret.
Plan rotation so both FortiAuthenticator and the NAS can be changed without a prolonged authentication outage.
Require Message-Authenticator where the client supports it
Current FortiAuthenticator RADIUS client resources include a setting to require the Message-Authenticator attribute.
This strengthens integrity for relevant RADIUS exchanges and should be enabled where protocol/client compatibility allows.
Validate every NAS before enforcing globally; older devices or unusual RADIUS implementations can fail if they do not send the required attribute.
Policies determine authentication logic
Current FortiAuthenticator uses RADIUS policies to choose authentication type, identity source, username format, groups/criteria, response attributes, and other logic.
Separate policies by use case: employee 802.1X, VPN MFA, device/MAB, administrative access, guest, and machine authentication often need different conditions.
Keep a clear first-match/selection design so overlapping client or attribute criteria do not send requests into the wrong authentication flow.
Prefer certificate-based EAP for managed device access
FortiAuthenticator supports certificate-based EAP flows such as EAP-TLS for relevant deployments.
EAP-TLS removes password replay from the network-access exchange and lets organizations tie access to device/user certificates.
Certificate lifecycle, revocation, trust chain, enrollment, and machine/user mapping become core dependencies, so use Certificate Lifecycle Automation to keep the PKI operational.
MFA belongs in the RADIUS policy where risk requires it
FortiAuthenticator examples show password/OTP and mandatory two-factor RADIUS policies for VPN/network access use cases.
Use MFA for remote/privileged access while avoiding interactive OTP requirements on machine authentication or noninteractive 802.1X flows that cannot support them.
Policy should match the endpoint/user experience instead of imposing the same factor sequence on every RADIUS transaction.
Accounting enables session visibility and enforcement
RADIUS accounting can record start/stop/update information and support usage enforcement.
FortiAuthenticator clients can also support RADIUS Disconnect messages where the NAS supports them.
Use accounting for session investigations and dynamic revocation, but confirm the NAS sends consistent session identifiers and the accounting path is as resilient as authentication.
Enable RADIUS service on the correct interfaces
Current documentation notes that RADIUS-related services must be enabled on the FortiAuthenticator network interface receiving requests.
Restrict management and RADIUS exposure to intended networks, apply firewall controls, and monitor unexpected sources.
Current FortiAuthenticator ports documentation lists UDP/1812 for RADIUS authentication and UDP/1813 (plus legacy accounting port support) for accounting; RADSEC/TLS support uses separate transport where configured.
High availability should match geography and authentication mode
FortiAuthenticator supports active-passive cluster HA with full configuration synchronization and active-active load-balancing with a standalone primary plus geographically separated load balancers.
Current docs say load-balancing mode is intended primarily for two-factor authentication and synchronizes a subset of configuration including RADIUS service.
Design NAS server lists, DNS/load balancing, heartbeat/sync, and failover tests before declaring the authentication service highly available.
Logging should identify client, policy, realm, method, and result
Monitor FortiAuthenticator authentication logs and forward them into FortiAnalyzer Detection Rules/event handlers for brute-force, impossible-travel, or suspicious login patterns where applicable.
Current FortiAnalyzer SOC architecture includes predefined FortiAuthenticator-related handlers for suspicious authentication activity.
Retain enough history to distinguish a user typo from distributed password spray or device misconfiguration.
FortiAuthenticator RADIUS succeeds when availability and policy are designed together
The mature deployment uses unique clients/secrets, strong message integrity, separate policies by use case, certificate/MFA methods where appropriate, accounting/disconnect, protected interfaces, HA/load balancing, and centralized authentication logging.
RADIUS is reliable when every NAS knows exactly which server/policy to use and the identity team can explain what happens during credential, network, or appliance failure.
RADIUS client groups introduced in newer FortiAuthenticator releases can simplify policy where many NAS devices share identical treatment. Use groups to reduce configuration repetition, but do not group devices from different trust zones merely for convenience. One shared secret or policy across hundreds of devices increases blast radius when one device is compromised.
RADIUS-over-TLS (RADSEC) can protect authentication traffic over untrusted or cross-site networks where supported, avoiding reliance on UDP plus a shared secret alone. Current FortiAuthenticator port documentation lists TCP/2083 for RADSEC. Design certificate trust, server identity, client support, and failover before using it as a replacement for classic UDP RADIUS.
EAP method selection must follow supplicant and credential capabilities. EAP-TLS offers strong certificate-based authentication; tunneled password/OTP methods may be needed for VPN or legacy devices; MAB is not equivalent to user/device cryptographic authentication. Separate assurance levels in policy so a MAC-address fallback never gains the same network access as a validated certificate.
Authorization attributes should be standardized. RADIUS responses can carry VLAN, group, role, Fortinet vendor-specific attributes, or other network policy data. Keep attribute dictionaries, allowed values, and NAS behavior documented so changing one policy does not put users into the wrong VLAN or privilege role across switches and firewalls.
Accounting data should be tested for start, interim update, stop, and disconnect behavior. Missing Stop records or inconsistent Session-Id/Acct-Session-Id can make active-session tracking unreliable. Use usage enforcement only after confirming the NAS sends the attributes FortiAuthenticator expects throughout roaming, reconnect, and device reboot.
Authentication order and remote identity sources can introduce latency. If a RADIUS policy checks LDAP/AD, remote RADIUS, certificates, tokens, or several realms sequentially, slow or unavailable upstream services can turn one login into multi-second timeouts. Monitor dependency latency and design fast failure or HA for the identity source itself.
Certificate validation for EAP-TLS should include revocation and trust lifecycle. Expired CRLs/OCSP outages, missing intermediates, or new enterprise CA chains can cause mass authentication failures. Test certificate rollover with a pilot group and publish support guidance for machines that cannot renew before the old trust path expires.
HA failover should be tested from each NAS type. A firewall, switch, wireless controller, and VPN gateway can have different timeout/retry/server-priority behavior. Simulate primary FortiAuthenticator loss and verify the NAS moves to secondary/load balancer quickly without creating duplicate accounting or lockout storms.
Shared secrets and client configuration should be rotated through automation where scale justifies it. Current FortiAuthenticator exposes REST API resources for RADIUS clients. Use controlled automation to inventory/update clients, but protect API credentials and verify NAS-side updates before removing the old secret.
Security operations should detect anomalous RADIUS patterns: password spray across accounts, one user across impossible locations, repeated rejects from an unknown NAS IP, sudden surge in MAB, policy changes, or repeated Message-Authenticator failures. Forward FortiAuthenticator logs to FortiAnalyzer and map detections to identity-response procedures.
RADIUS timeouts and retransmissions should be tuned consistently on NAS devices. Aggressive retries can amplify an outage and produce duplicate accounting; overly long timeouts create painful user delays. Test failover timing with the actual switch/firewall/VPN software versions in use.
Realm design should prevent ambiguous usernames. Decide whether users authenticate as `user`, `user@realm`, or another canonical format and normalize consistently. Duplicate usernames across directories are dangerous when policy can route the request to the wrong identity source.
Administrative changes to RADIUS clients and policies should be sent to centralized audit logging. Current FortiAuthenticator logs configuration changes and RADIUS service restarts when relevant settings change. Alert on unexpected policy/client edits because one change can affect authentication for many NAS devices.
Capacity planning should use current FortiAuthenticator model/licensing limits for users, RADIUS clients, policies, and authentication throughput. Avoid copying limits from older appliance generations; validate the exact hardware/VM license and release notes before a large rollout.
RADIUS design should include maintenance-mode behavior. Firmware upgrades, certificate replacement, directory outages, and HA maintenance can remove one server temporarily. NAS devices should have tested secondary server configuration, and change windows should confirm active sessions versus new authentications behave as expected.
Document the relationship between RADIUS authentication and downstream authorization. A successful Access-Accept may place users into VLANs, roles, firewall groups, or VPN portals. Changes to response attributes should therefore be tested end to end, not only by seeing ‘authentication successful’ in FortiAuthenticator.
RADIUS resilience should be tested with realistic authentication paths and failure order. Network devices, redundant FortiAuthenticator nodes, directory dependencies, certificates, and accounting behavior need to fail in known ways so an identity outage does not become an uncontrolled access decision.
