How should security teams handle RADIUS access when they want to keep existing FortiGate groups in place?

Keeping FortiGate groups intact while moving RADIUS authentication upstream

The cleanest pattern is to preserve the FortiGate group model and change the source of truth behind it. In practice, that means the firewall still evaluates the same local or mapped groups, but those memberships are populated from a directory-backed identity layer rather than maintained manually on the appliance. That preserves operational continuity while making authentication and access decisions easier to centralise.

Done well, this is a migration of control plane, not a redesign of policy. Teams keep the device-side authorization structure that users and administrators already understand, then bind it to centrally managed identities, MFA, and group membership logic. The main benefit is that the access path becomes easier to audit, rotate, and troubleshoot without changing the practical access model on the FortiGate.

One useful way to think about it is that RADIUS becomes the decision and assertion layer, while the FortiGate remains the enforcement point. If the appliance has to be rebuilt around new groups or ad hoc local users, you usually introduce unnecessary drift and make later remediation harder. If the mapping is stable, you can adjust identity policy centrally without reworking the network access design each time membership changes.

What usually breaks during this kind of migration

The common failure is not authentication itself, but inconsistency between directory groups, RADIUS attributes, and the FortiGate objects that consume them. If the group mapping is ambiguous, access can appear to work for some users while silently failing for others, especially where role-based access is layered on top of legacy local groups or where administrators assume the directory name alone is enough.

Another source of trouble is scope creep. Teams sometimes take the opportunity to redesign every policy, rename every group, and change the administrative model at the same time. That creates avoidable outage risk. A safer approach is to keep the device posture stable first, verify that authenticated users land in the intended FortiGate groups, and only then consider whether the policy structure itself should be simplified later.

Operationally, the goal is to avoid making the firewall depend on manual account management or duplicated access logic. When the same person can be provisioned in the directory but still excluded from the firewall because the mapping is stale, the result is not stronger security, it is hidden fragility. The best implementations keep the access rule structure durable and let the identity layer do the moving.

How to preserve access intent without rebuilding the rule set

Start by inventorying the existing FortiGate groups and the specific access outcomes they represent, such as admin access, read-only access, or VPN user roles. Then define the equivalent directory groups or claims that should feed those roles, and confirm that the RADIUS response can carry the right membership signal consistently. The practical test is simple: does the same user end up with the same effective privilege after the identity source changes?

Next, verify the parts of the access path that are often overlooked: MFA trigger points, break-glass access, group nesting, and how disabled or removed users are handled. If the directory and RADIUS policy are correct but the FortiGate still trusts old local objects or cached memberships, you can end up with a control gap that is hard to see until an incident or audit exposes it.

For teams modernising the access stack, the strongest pattern is to centralise the identity decision and leave the appliance-specific group structure as the presentation layer. That reduces repetitive admin work, keeps the rollout reversible, and avoids the trap of treating a migration as a chance to re-encode every local exception into a new model.

Risk and Threat Considerations

When FortiGate groups are preserved but the upstream identity mapping is weak, the main risk is privilege drift, where users keep access they should no longer have or lose access they still need for operations. A second risk is overtrust in group labels, because the label on the firewall may look correct even when the directory source or RADIUS attribute has become stale.

Failure mechanism: Manual group maintenance, inconsistent RADIUS attribute mapping, or delayed deprovisioning can leave the appliance enforcing an access decision that no longer matches the intended identity state.

Impact: The result can be unauthorized administrative access, failed revocation, or misleading audit evidence, especially when the firewall still appears aligned with policy at the object level.

Practitioner Guidance

What to verify: Confirm that every FortiGate group has one explicit upstream identity source and one documented fallback path for exceptions. If a group cannot be traced from identity source to effective firewall privilege, treat it as a control gap rather than a configuration detail.

What good looks like: A user or administrator changes roles in the directory, the mapped FortiGate group changes predictably, and the resulting access is visible in logs without local device edits. That is the sign that the appliance is enforcing policy while the directory is governing membership.

Practitioner takeaway: Preserve the firewall groups if they are already the right enforcement shape, but move the authority for membership out of the appliance and into a centrally governed identity layer so changes stay auditable and reversible.

Related resources from NHI Mgmt Group

• How should security teams evaluate MDR coverage when they want to keep their existing SIEM platform?
• How should security teams handle TOTP credentials when users want to keep authenticator access off the phone?
• How should security teams handle service access when static secrets keep leaking?
• How should security teams handle access requests when ITSM tools are already in place?