RADIUS Change of Authorization is a mechanism that lets a RADIUS server change a client’s access rights after the original session is established. It is used to move users or devices between policies without reconnecting. Secure deployments restrict who can send it, verify session targeting, and monitor unexpected reauthorisation events.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | CoA changes session rights for services and devices through trusted RADIUS control paths. |
| AC-16 — Security and Privacy Attributes | CoA often updates session attributes that drive dynamic access decisions. | |
| AU-2 — Event Logging | CoA should create auditable reauthorization and session-change events. | |
| Recommendation — Apply IA-9 to tightly authenticate and authorize the control channel that can alter active access sessions. Use AC-16 to bind policy changes to explicit session attributes and enforce them consistently. Log CoA requests and resulting policy changes so unexpected reauthorization events can be reviewed. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | CoA is an access-control operation that changes active permissions after session start. |
| Recommendation — Manage CoA under access-control governance so only approved systems can modify live session rights. | ||
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.