Change of Authorization (CoA) in 802.1X: How It Works and How to Configure It

What CoA Is and Why It Exists

Standard RADIUS is a pull model. The switch (authenticator) contacts the RADIUS server when a client connects, receives an Accept or Reject, and applies the policy. That policy remains static until the session ends or the client re-authenticates. RADIUS Change of Authorization — defined in RFC 5176 — inverts that model. It gives the RADIUS server the ability to push a policy update to the switch mid-session, without any action from the endpoint.

The practical value of CoA becomes clear in a few specific scenarios:

Posture remediation. Cisco ISE performs a posture assessment after initial authentication. The endpoint first lands in a quarantine VLAN or gets a restrictive dACL. Once ISE's posture agent confirms the machine is compliant, ISE sends a CoA to the switch telling it to reassign the session to the correct VLAN and apply a permissive dACL. The user never disconnects. The policy change is transparent.

Security incident response. SOC analysts use ISE's Adaptive Network Control (ANC) to quarantine or terminate sessions on endpoints that show signs of compromise. A single click in ISE triggers a CoA that either drops the session or pushes a quarantine ACL — without touching the switch CLI.

Conference room re-provisioning. When a managed endpoint leaves and a guest device connects to the same port, CoA lets ISE push a new policy immediately rather than waiting for the port to cycle.

Manual policy updates. When an authorization rule changes — a new dACL version, an updated VLAN assignment — CoA lets you push that change to active sessions without a maintenance window.

CoA is not a convenience feature. In any ISE deployment using posture, profiling, or ANC, CoA is a hard dependency.

CoA Message Types

RFC 5176 defines two CoA message types, and IOS XE supports both:

CoA-Request (code 43). The RADIUS server sends this to the NAS (switch). It contains the session identifier (typically Calling-Station-ID or Acct-Session-ID) plus the new attributes to apply — VLAN, dACL, URL redirect, or a disconnect trigger.

CoA-ACK (code 44). The NAS sends this back when it successfully applied the change.

CoA-NAK (code 45). The NAS sends this when it cannot apply the change. The Error-Cause attribute in the NAK tells you why.

Disconnect-Request (code 40). A special CoA subtype that terminates a session entirely. The NAS drops the session; the client must re-authenticate from scratch.

IOS XE supports the following CoA actions:

IOS XE CoA Configuration

The configuration has two parts: enabling dynamic authorization globally and pointing ISE at the right interface.

! --- Global AAA and RADIUS baseline (must already be in place) ---
aaa new-model
!
radius server ISE-PRIMARY
 address ipv4 10.0.0.10 auth-port 1812 acct-port 1813
 key ISEsecret123
!
aaa group server radius ISE-SERVERS
 server name ISE-PRIMARY
!
! --- Enable dynamic authorization (CoA) ---
aaa server radius dynamic-author
 client 10.0.0.10 server-key ISEsecret123
 port 3799
 auth-type any
!
! --- Ensure the switch source-interfaces its RADIUS traffic correctly ---
ip radius source-interface Vlan99

Line-by-line breakdown:

aaa server radius dynamic-author — This is the IOS XE command that enables RFC 5176 dynamic authorization. Without this block, the switch will silently drop all incoming CoA-Request packets from ISE.

client 10.0.0.10 server-key ISEsecret123 — Defines ISE as an authorized CoA client. The shared secret here must match the secret configured in ISE for this Network Device entry. If they mismatch, all CoA packets are rejected with a CoA-NAK containing Error-Cause = Invalid-Key.

port 3799 — This is the IANA-assigned port for RADIUS dynamic authorization. ISE sends CoA packets to UDP/3799 on the switch management IP. Some older documentation references port 1700, which is a Cisco proprietary CoA port used before RFC 5176. Use 3799 for all modern deployments.

auth-type any — Accepts CoA packets that authenticate using either the shared secret alone or shared secret plus the Message-Authenticator attribute. Leave this as any unless your security policy mandates all, which requires Message-Authenticator on every packet.

ip radius source-interface Vlan99 — The switch sends its RADIUS requests and receives CoA responses on the management VLAN interface. ISE must be able to reach this IP. If the switch uses a different source address than what ISE expects (based on the Network Device definition), CoA will fail because ISE validates the source IP against its device list.

ISE Configuration for CoA

Step 1: Enable CoA on the Network Device

Navigation: Administration > Network Resources > Network Devices > [Select device] > RADIUS Authentication Settings

In the Network Device entry for your Catalyst 9300 (IP 10.0.99.1 or whichever management IP ISE uses to identify the device), scroll to the CoA section:

• CoA Port: 3799
• RADIUS UDP Ports: 1812, 1813 (standard)

The Network Device entry does not have a separate CoA toggle — CoA capability is implicit when you configure the shared secret and ISE knows the device supports it. The key is that ISE must send CoA packets to the correct IP (the switch management IP) and the switch must have that ISE IP listed in aaa server radius dynamic-author.

Step 2: Configure CoA in Authorization Profiles

Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles

Each Authorization Profile in ISE can include a CoA action. The most common use case is in posture remediation:

• Posture Unknown Profile: URL redirect to the Client Provisioning portal + restrictive dACL
• Compliant Profile: Full VLAN assignment, permissive dACL, no redirect

When ISE detects the posture status changes from Unknown to Compliant, it sends a CoA-Request to the switch. The CoA type you configure in the Authorization Profile is:

• Reauthenticate — triggers a new RADIUS exchange; ISE then applies the Compliant profile
• Port Bounce — use only when the endpoint needs a DHCP release/renew (e.g., VLAN change requires new IP)

Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles > [Profile Name] > Common Tasks

Under "Common Tasks," check "DACL Name" and select your compliant dACL. Under the "Advanced Attributes Settings" area you can add Cisco-AVPair = subscriber:command=reauthenticate if building a custom profile, but standard ISE Authorization Profiles handle this via the CoA type dropdown.

Step 3: ISE Policy Set Authorization Rules with CoA

Navigation: Policy > Policy Sets > [Your Policy Set] > Authorization Policy

A typical posture-based policy set has rules in this order:

When the posture agent reports compliance, ISE re-evaluates the session and sends a CoA that moves the client from the "Unknown Posture" result to the "Compliant Employees" result.

Step 4: Trigger CoA Manually from ISE Live Sessions

Navigation: Operations > RADIUS > Live Sessions

Find the active session, right-click it:

• Reauthenticate — ISE sends a CoA-Request with the reauthenticate action
• Disconnect — ISE sends a Disconnect-Request (session termination)
• Change Authorization — available with ANC policies; lets you apply a quarantine or unquarantine policy

This interface is invaluable for testing CoA during lab validation. Authenticate a client, verify the session appears in Live Sessions, trigger a manual Reauthenticate, and watch debug radius on the switch to confirm the CoA exchange.

Verifying CoA Operation

Show Commands

SW9300# show aaa server

Sample output:

RADIUS: id 1, priority 1, host 10.0.0.10, auth-port 1812, acct-port 1813
     State: current UP, duration 3d02h, previous duration 0s
     Dead: total time 0s, count 0
     Platform State from SMD: current UP, duration 3d02h, previous duration 0s
     Platform Dead: total time 0s, count 0
     UP/DOWN: #times 1, #failed transitions 0
     Authentication: #sent 1432, #received 1432
     Retransmission: #sent 0, #late responses 0, #bad responses 0
     CoA: #received 47, #responses 47, #errors 0
     Estimated Outstanding Access Transactions: 0
     Estimated Outstanding Accounting Transactions: 0
     Estimated Throttled Access Transactions: 0
     Estimated Throttled Accounting Transactions: 0
     Maximum Throttled Transactions: access 0, accounting 0
     Requests per minute past 1 hours: 0 maximum, 0 average, 0 current

Dynamic Authorization:
  Dynamic Authorization Clients allowed (3799/udp):
    10.0.0.10 (port 3799): #CoA Request Received: 47, #CoA Request Success: 47

The CoA: #received 47, #responses 47, #errors 0 line confirms the switch is receiving and acknowledging CoA requests. If #errors is non-zero, move to the troubleshooting section below.

SW9300# show authentication sessions interface GigabitEthernet1/0/5 details

Sample output after a CoA reauthentication:

            Interface:  GigabitEthernet1/0/5
          MAC Address:  a4b1.c2d3.e4f5
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.10.25
           User-Name:  CORP\jsmith
              Status:  Authorized
              Domain:  DATA
      Reauthentication:  Timer Running (1800s remaining)
         CoA-Capable:  Yes
        Session timeout:  36000s (server), Remaining: 31200s
           Idle timeout:  N/A
      Common Session ID:  0A0063010000002B1A3F4C92
        Acct Session ID:  0x0000002C
               Handle:  0x98000029
       Current Policy:  POLICY_Gi1/0/5

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_MUST_SECURE (priority 150)

Server Policies:
     Vlan Group:  Vlan: 10
           ACS ACL:  xACSACLx-IP-Employee-Compliant-12345678

Method status list:
       Method           State
       dot1x            Authc Success

Note CoA-Capable: Yes — this confirms the session was established through a CoA-aware authentication exchange.

SW9300# show aaa sessions

This command shows all active AAA sessions and their session IDs, which ISE uses to target specific CoA requests.

Debug Commands

Use these during initial validation. Do not leave enabled in production.

SW9300# debug radius
SW9300# debug aaa authorization
SW9300# debug dot1x all

A successful CoA exchange in debug radius output:

*Mar 19 09:14:22.341: RADIUS: Received from id 1645/47 10.0.0.10:51234, CoA Request, len 148
*Mar 19 09:14:22.341: RADIUS:  authenticator BA 2F C1 44 ...
*Mar 19 09:14:22.342: RADIUS:  Calling-Station-Id  [31] 19 "A4-B1-C2-D3-E4-F5"
*Mar 19 09:14:22.342: RADIUS:  Acct-Session-Id     [44] 10 "0000002C"
*Mar 19 09:14:22.342: RADIUS:  Cisco AVPair        [1]  35 "subscriber:command=reauthenticate"
*Mar 19 09:14:22.343: RADIUS: Sending CoA ACK to 10.0.0.10:51234

If the switch sends a CoA-NAK, the debug radius output shows Error-Cause:

*Mar 19 09:14:22.343: RADIUS: Sending CoA NAK to 10.0.0.10:51234
*Mar 19 09:14:22.343: RADIUS:  Error-Cause         [101] 6 502

Error-Cause 502 = Request Not Routable (session not found). Error-Cause 401 = Unsupported Attribute. Error-Cause 402 = Missing Attribute.

CoA in Port-Bounce Scenarios

Port-bounce sends a CoA-Request with the subscriber:command=bounce-host-port AVPair. The switch shuts the port for a configurable interval (default 10 seconds) and then re-enables it. The endpoint loses link, which forces a full DHCP release/renew. Use this when:

• A VLAN change requires the endpoint to get a new IP from the new VLAN's DHCP scope
• A phone is re-provisioned and needs to restart its LLDP/CDP negotiation

Be careful with port-bounce in multi-host or multi-auth environments. Bouncing the port disconnects all sessions on that port, not just the targeted one. If a data endpoint and a phone are both on the same port (multi-domain auth), bouncing the port for one affects both.

To trigger port-bounce from ISE: Operations > RADIUS > Live Sessions > right-click session > Change Authorization > select ANC policy with bounce action, or configure it as a CoA type in the Authorization Profile used during posture remediation.

CoA and VLAN Reassignment

When ISE sends a CoA that changes the VLAN assignment (e.g., from quarantine VLAN 40 to data VLAN 10), the switch updates the port VLAN. However, the endpoint's IP address does not automatically change. The endpoint still holds its DHCP lease from VLAN 40's scope.

For the VLAN change to be fully effective, the endpoint needs to release and renew its IP. There are three ways to handle this:

1. Port-bounce CoA. ISE sends a bounce action instead of a reauthenticate action. The port cycles, the endpoint negotiates a new connection, gets a new VLAN assignment, and obtains a new IP from the correct DHCP scope. This is the most reliable method.

2. Client-side DHCP renewal. Some posture agents (Cisco AnyConnect ISE posture module) can trigger a DHCP release/renew on the endpoint after successful posture. This avoids port-bounce entirely.

3. Short DHCP lease. Configure short leases on the quarantine VLAN scope so endpoints pick up new addresses quickly. This is a workaround, not a solution.

In production campus deployments, port-bounce CoA is the standard approach for posture-based VLAN reassignment. For dACL-only changes (no VLAN change), use reauthenticate — the endpoint keeps its IP and the new dACL takes effect without any connectivity disruption.

Troubleshooting CoA

Symptom: Switch receives CoA from ISE but sends CoA-NAK with Error-Cause 503 (Session Context Not Found)

Cause: ISE is referencing a session that the switch does not have in its session table. This happens when the switch has cleared the session (link-down event, manual clear), but ISE still shows the session as active because the accounting STOP packet has not been received or processed yet.

Fix: On ISE, navigate to Operations > RADIUS > Live Sessions, filter by the endpoint MAC, and verify the session state. If the session shows active but the switch port is down, force-expire the session from ISE or wait for the accounting timeout. On the switch, run show authentication sessions to confirm the session is present before testing CoA. If sessions are not persisting through link events, check authentication event server dead action configuration.

Symptom: CoA packets arriving at switch but being silently dropped, no debug output

Cause: The aaa server radius dynamic-author block is missing or the client statement for ISE's IP is absent. The switch only accepts CoA from explicitly listed clients.

Fix: Verify the configuration block:

SW9300# show running-config | section dynamic-author
aaa server radius dynamic-author
 client 10.0.0.10 server-key ISEsecret123
 port 3799
 auth-type any

If this section is missing or the client IP does not match ISE's sending IP, add it. Also confirm ISE's send IP with show aaa server — ISE may be sending CoA from a different interface (PSN vs Management IP) than you expect.

Symptom: CoA works for reauthenticate but VLAN does not change on the endpoint after posture compliance

Cause: ISE is sending a reauthenticate CoA (correct), the switch re-authenticates the client and receives a new VLAN assignment, but the endpoint's IP address is from the old VLAN and the DHCP scope.

Fix: Switch to port-bounce CoA for posture-based VLAN transitions. In ISE, update the posture remediation Authorization Profile:

Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles > PostureRemediation > Common Tasks

Set "CoA type" to "Port Bounce" instead of "Reauthenticate". This causes ISE to send a bounce CoA after posture compliance is confirmed, which cycles the port and forces a fresh DHCP acquisition from the correct VLAN's scope.

Symptom: ISE Live Sessions shows CoA sent but the switch logs show nothing received

Cause: Firewall or ACL blocking UDP/3799 between ISE and the switch management interface.

Fix: Run a packet capture on the switch management VLAN interface:

SW9300# monitor capture CAP interface Vlan99 both
SW9300# monitor capture CAP match udp any host 10.0.99.1 eq 3799
SW9300# monitor capture CAP start

Trigger a CoA from ISE and check:

SW9300# monitor capture CAP stop
SW9300# show monitor capture CAP buffer brief

If no packets arrive, the issue is upstream — check ACLs on any firewall or router between ISE and the switch management VLAN. Also verify ip radius source-interface points to the correct interface that ISE can reach.

CoA and High Availability

In a redundant ISE deployment (two PSNs), CoA adds a layer of complexity. The switch sends accounting requests to one PSN; ISE tracks the session on that PSN. When a CoA needs to be sent, ISE must send it from the PSN that owns the session, not the standby. ISE handles this internally through session replication between PSNs, but session sync has a small delay window.

If you trigger a CoA immediately after failover (the primary PSN just went down), there is a risk ISE has not fully replicated the session to the secondary. The CoA-NAK with Error-Cause 503 (Session Not Found) is the result.

For RADIUS redundancy configuration, see Article 28: RADIUS Redundancy and Failover in 802.1X Deployments.

Ensure your aaa server radius dynamic-author block lists both PSNs as valid clients:

aaa server radius dynamic-author
 client 10.0.0.10 server-key ISEsecret123
 client 10.0.0.11 server-key ISEsecret123
 port 3799
 auth-type any

Both PSNs need to be listed because either one might originate a CoA depending on which owns the session.

Production Deployment Notes

In a campus access layer deployment with 48-port switches and 500+ endpoints, CoA operation at scale requires:

• Accounting enabled and reliable. CoA targeting uses the Acct-Session-ID. If accounting is not running or packets are being dropped, ISE cannot reliably target sessions.
• Session ID consistency. The Acct-Session-Id attribute in the accounting packets must match what ISE tracks. Verify with debug radius accounting.
• CoA timeout tuning. The default CoA response timeout on ISE is 5 seconds. In high-latency environments (branch office over WAN), increase this under Administration > System > Settings > RADIUS > CoA timeout.
• Monitoring CoA errors. ISE's Operations > Reports > Endpoints and Users > Change of Authorization report shows CoA success and failure history per device. Review this report after any policy change that triggers mass CoA events.

What's Next: Article 20 — 802.1X Authentication Failing: Where to Start Troubleshooting — covers the structured diagnostic approach for 802.1X failures, from physical layer checks through RADIUS packet analysis, with the specific show and debug commands that cut diagnosis time from hours to minutes.