RADIUS Change of Authorization

What Change of Authorization Means in RADIUS

Change of Authorization, often shortened to CoA, is what makes RADIUS policy dynamic after login. Instead of treating authentication as a one-time event, it gives the server a way to ask the access device to alter the session when policy, posture, or role changes.

That makes CoA operationally important in environments that need to move a user or device between access states without forcing a disconnect. It is a control-plane action, not a new login, so its value depends on the access device correctly honoring the update and the server targeting the right session.

How CoA Changes Active Sessions

CoA exists because many network decisions are not static. A device may start in a guest, quarantine, or limited-access state and later qualify for broader access; conversely, a healthy session may need to be downgraded immediately when risk changes.

In practice, CoA can trigger reauthorization, VLAN reassignment, policy refresh, or session termination depending on what the access device supports. The important point is that the original session remains in place while its rights are adjusted, which is why session targeting and policy consistency matter so much.

Because CoA is session-specific, a deployment must be able to identify the exact active session it intends to affect. If that targeting is weak, the server can send a valid-looking request that lands on the wrong session, the wrong device, or no session at all.

Security Controls Around CoA

CoA is only safe when the party sending it is tightly restricted. A well-run deployment limits who can issue CoA, protects the channel used to carry it, and ensures the access device will only honor updates from trusted RADIUS infrastructure.

Operationally, the best deployments treat CoA as part of a larger access-control design rather than a standalone feature. The same NAC design that uses dynamic policy should also track device identity, session ownership, and policy state so that reauthorization events are intentional rather than surprising. Network Access Control (NAC) Guide is the clearest internal reference for that model.

CoA also sits alongside broader authorization design choices. If an environment uses different policy tiers for users, workloads, or devices, the authorisation model should be explicit enough that a CoA event maps to a known rule rather than an ad hoc change. Authorisation Models Guide is useful when teams need to reason about how the policy decision itself is structured.

Detection, Monitoring, and Failure Modes

CoA should generate visible administrative events, because unexpected reauthorization is often a sign of misconfiguration, automation error, or abuse. Monitoring should look for unusual timing, repeated policy flips, failed session targeting, and CoA bursts that do not align with normal access lifecycle changes.

The biggest failure modes are stale session state, overbroad administrative access, and policy drift between the RADIUS server and the access device. If the access device cannot reliably apply the requested change, a session may appear updated while still retaining broader access than intended.

CoA can also become a persistence or lateral-movement aid if an attacker reaches the control path that sends it. In that case, the problem is not authentication itself, but the ability to silently alter an active session’s privileges after the session has already been established.

Where teams need incident context, Salt Typhoon telecom intrusions 2025 is a useful reminder that network control-plane secrets and remote access mechanisms are attractive targets once an environment is compromised.

Practitioner Guidance

Why practitioners should care: CoA is valuable because it lets you enforce policy changes without waiting for a reconnect, but that same power makes it sensitive to trust, targeting, and admin-path security. Treat it as a privileged network action, not a convenience feature.

What to watch for: Repeated reauthorization events, policy changes that do not match user or device state, and CoA activity outside normal operational windows usually deserve investigation. Those signals often indicate misrouted requests, automation defects, or unauthorized control-plane access.

Practitioner takeaway: If CoA is part of your access design, document who can send it, which sessions it may affect, and what telemetry proves that the requested policy change actually took effect.

Related resources from NHI Mgmt Group

• Why does redirectless authorization change the trust model for IAM teams?
• Why do agents change the way IAM teams think about authorization?
• How do AI agents change the way IAM teams think about authorization?
• Why do embedded policy decision points change the risk model for authorization?