RADIUS Change of Authorisation lets a server update an active session’s access without waiting for the session to end. It can change permissions, apply a new policy, or disconnect a user or device. Defenders should protect the control channel, restrict who can send change requests, and monitor for unexpected mid-session policy changes.
How RADIUS Change of Authorisation changes an active session
RADIUS CoA is a mid-session control plane action, not a fresh login. The access server keeps the session up, then receives a request that tells it to alter the user or device state already in place. That is why CoA is useful for rapid policy enforcement, quarantine, or disconnects when posture, role, or trust conditions change after access begins.
In practice, CoA matters because the original authentication decision does not stay static. Network access control systems often pair session control with policy engines so a device can be moved from normal access to restricted access without waiting for reauth. That makes the control operationally powerful, but also sensitive to trust relationships between the policy source and the network access equipment. Network Access Control (NAC) Guide
CoA is also a lifecycle and governance mechanism, because it lets defenders react when the access state becomes wrong after session establishment. If a user loses compliance, a device changes posture, or a policy engine reclassifies the connection, CoA can update access without waiting for a timeout. That same flexibility is why session ownership, policy authority, and auditability matter as much as the packet exchange itself. IAM and IGA Basics
What changes during a CoA request
A CoA request can modify the effective access granted to the session. Common outcomes include a different policy set, a different VLAN or role mapping, a forced reauthentication, or a full disconnect. The exact effect depends on what the NAS, switch, wireless controller, VPN gateway, or other enforcement point supports, so the server is asking the access device to change state on the live session rather than rebuilding the connection from scratch.
The important detail is that CoA is stateful. The session already exists, so the control has to target the right session context and arrive on a path the network device trusts. That makes CoA different from general authorization logic: it is an enforcement update for an existing session, usually driven by a policy change, a posture signal, or a manual administrative action. Authorisation Models Guide
When implemented well, CoA is part of a broader access governance pattern: discover the session, decide what the new policy should be, and push the update quickly enough that the old access does not remain useful. That is especially important when permissions are time-sensitive, such as after device noncompliance, compromised credentials, or a role change that should take effect immediately. NHI Lifecycle Management Guide
Why CoA depends on trust, control, and monitoring
CoA is only as safe as the channel and authorization around it. If an attacker can spoof or abuse change requests, they can disrupt access, suppress controls, or force repeated session churn. If defenders do not log and review mid-session changes, a legitimate-looking policy update can hide a real compromise or an administrative mistake.
The failure mechanism is straightforward: a trusted network element accepts an update that should have come only from an approved policy source, or it accepts a valid source but applies the change to the wrong session. The impact can be loss of service, silent privilege reduction or expansion, or a missed opportunity to contain a compromised endpoint before it keeps moving through the network. Top 10 NHI Issues
CoA also sits close to the same abuse patterns that show up when access control keys, shared secrets, or network management credentials are exposed. In real intrusions, attackers often value these materials because they help them persist, pivot, or alter policy on infrastructure that would otherwise constrain them. The lesson for defenders is that session control mechanisms deserve the same protection mindset as authentication secrets. Salt Typhoon telecom intrusions 2025
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CoA relies on controlled credentials and request secrets for trusted session updates. |
| AC-2 — Account Management | CoA changes active access state and may disable or reduce a session midstream. | |
| AU-2 — Event Logging | CoA needs traceable logs for unexpected policy changes and session actions. | |
| Recommendation — Protect and rotate the secrets that authorize session change requests. Update or revoke account access promptly when session risk changes. Log every CoA request, decision, and enforced session change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | CoA is an access-control action that must be tightly restricted and reviewed. |
| Recommendation — Restrict who can issue mid-session access changes and review that access regularly. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | CoA modifies active access and depends on strong session authorization and trust. |
| Recommendation — Enforce least privilege for session-change authority and verify requester legitimacy. | ||
Practitioner Guidance
What to verify: Confirm which devices are permitted to send CoA, which session attributes they may change, and whether those requests are authenticated and logged end to end. If you cannot prove requester identity and session targeting, treat the CoA path as a privileged control surface rather than a routine network feature.
Decision rule: If the change is meant to reduce exposure, prefer a restrictive session update or disconnect over a soft policy tweak when the endpoint is already suspect. If the goal is policy correction for a healthy session, keep the change narrow so you do not create avoidable disruption for unaffected users or devices.
What good looks like: CoA events are rare, explainable, and attributable to a clear policy trigger, with logs that show who requested the change, which session was altered, and why. When the same session receives repeated or unexpected changes, treat that as a signal that either the policy engine is unstable or the access path is being abused.
Practitioner takeaway: CoA is most valuable when it shortens the time between a changed trust decision and the enforced session state, but that only works if the change path itself is tightly controlled and observable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org