Standalone FortiSwitch 148F & Cisco ISE Integration

This is the textbook "802.1X passes but the port never moves to the assigned VLAN" failure. Access-Accept only means ISE authorized the session. It says nothing about whether the dynamic VLAN actually got applied to the port, and the "no DHCP, Unidentified Network" symptom means the endpoint is sitting in the wrong VLAN (almost always the port's native/default), where no DHCP server is reachable.

Run one command before changing anything. On the FortiSwitch, after the endpoint authenticates:

diagnose switch 802-1x status <port>

That output shows the Dynamic Authorized Vlan, the Native Vlan, the Allowed Vlan list, the Untagged Vlan list, and the session state. It splits your problem into two cases instantly:

• Dynamic Authorized Vlan is blank or equals the default native VLAN → the RADIUS VLAN is not being applied. Cause is the attributes or framevid-apply. This is the likely one.
• Dynamic Authorized Vlan shows the correct VLAN but DHCP still fails → the VLAN is assigned but isn't usable for untagged DHCP, so the problem is upstream forwarding, not authentication.

Case A: VLAN not applied (most likely). Three things, in order:

1. The RADIUS attributes ISE actually returns. Dynamic VLAN needs the three IETF tunnel attributes: Tunnel-Type = VLAN (13), Tunnel-Medium-Type = IEEE-802 (6), Tunnel-Private-Group-Id = the VLAN. Send the correct attributes and the FortiSwitch will override the port's native VLAN. Two classic ISE mistakes: omitting Tunnel-Medium-Type, or putting a VLAN name in Tunnel-Private-Group-Id that the switch can't map. Check ISE Live Logs for what was actually sent, and have ISE send the numeric VLAN ID unless you've defined a matching VLAN name on the switch.
2. set framevid-apply enable on the 802.1X security policy. This is the setting that applies the RADIUS-returned VLAN to the frames. If it's disabled, the port authenticates and then stays on its native VLAN, which is exactly your symptom. This is the single most common FortiSwitch-side cause.
3. The returned VLAN must exist on the FortiSwitch and be in the port's allowed/untagged VLAN lists. If ISE returns VLAN 50 but 50 isn't defined or isn't allowed untagged on that port, it can't be applied as the access VLAN.

Case B: VLAN applied but no DHCP. A standalone 148F is pure L2, so the DHCP server or relay lives upstream. If the assigned VLAN isn't carried on the uplink trunk toward the L3 gateway, the DHCP discover never reaches the server. Confirm the dynamic VLAN is trunked upstream and that DHCP relay/scope exists for it. Also confirm the client gets the VLAN untagged. If you're using the Egress-VLANID attribute (attribute 56) for non-native dynamic VLANs, 0x31 means tagged and 0x32 means untagged, and a client expecting untagged access tagged by mistake will never DHCP.

One standalone-specific caveat: almost every doc and forum example for this is written in FortiLink syntax (config switch-controller security-policy 802-1X). You're in standalone mode, so the equivalents are config switch security-policy 802-1X for the policy, config switch interface with set security-groups to bind it to the port, and the same fields (security-mode, framevid-apply, eap-passthru). Don't copy the managed-mode snippets verbatim. Verify against the FortiSwitchOS standalone admin guide for your exact version.

Most probable root cause given "auth succeeds, VLAN doesn't": either framevid-apply is disabled, or ISE is returning the VLAN as a name/incomplete attribute set. The diagnose switch 802-1x status output tells you which in one look, so start there.

You could start by checking the authentication status in the switch port: # diagnose switch 802-1x status

Additionally you can enable the fnbamd debug as shown here:

and also refer to the FNAC standalone FSW integration guide: https://docs.fortinet.com/document/fortinac-f/7.6.0/fortiswitch-standalone-integration/293596/4-radius-optional#_Toc207489839