TL;DR: RADIUS response forgery exploits MD5-based integrity checks in RADIUS so an attacker on-path can turn an Access-Reject into Access-Accept and gain unauthorized network access, according to JumpCloud. The issue is not just protocol weakness, it is a trust model that assumes response integrity can be inferred from a legacy authenticator.
At a glance
What this is: This is an analysis of RADIUS response forgery, a protocol-level attack that can convert denied authentication into approved access.
Why it matters: It matters because network access decisions still sit at the boundary of IAM and infrastructure, where forged responses can bypass controls and undermine both human and machine access governance.
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
👉 Read JumpCloud's analysis of RADIUS response forgery and CVE-2024-3596
Context
RADIUS response forgery is a protocol integrity problem, not a password problem. When the authenticity of an Access-Accept message can be forged, the control plane that decides whether a device or user gets on the network becomes a target in its own right, and traditional access assurance assumptions no longer hold.
For IAM and network teams, this is a reminder that authentication is only as strong as the integrity checks around it. The article sits squarely in the NHI and access governance space because shared secrets, transport security, and response validation all determine whether a network access device can trust what it receives.
Key questions
Q: How should security teams prevent RADIUS response forgery in enterprise networks?
A: Security teams should move high-value access paths off legacy RADIUS trust assumptions where possible, require Message-Authenticator, and use RadSec to protect traffic in transit. They should also prioritise EAP-TLS for stronger mutual authentication and segment access networks so on-path interception becomes much harder to achieve.
Q: Why do legacy RADIUS deployments create access control risk?
A: Legacy RADIUS deployments create risk because authorization can depend on weak or outdated integrity checks, not just on user credentials. If an attacker can intercept traffic and forge a valid-looking response, the network access device may grant access even though the server never approved it.
Q: What breaks when RADIUS response integrity is not protected end to end?
A: When response integrity is not protected end to end, an attacker can rewrite the meaning of the authentication decision itself. That turns network access control into a forgery problem, where the device trusts a manipulated Access-Accept message instead of a genuine server decision.
Q: Who is accountable when forged RADIUS responses allow unauthorized access?
A: Accountability should sit with the teams that own network access architecture, identity controls, and protocol hardening, because the failure spans all three. Zero Trust and access governance frameworks require validation of the control path, not just the user or device being authenticated.
Technical breakdown
How RADIUS response forgery defeats legacy integrity checks
RADIUS response forgery works because the protocol’s response authenticator depends on MD5 and predictable packet structure. An on-path attacker can intercept the Access-Request, manipulate response attributes, and exploit chosen-prefix collision properties to produce a forged response that still appears valid to the network access device. The protocol weakness is structural: if the client trusts the authenticator without stronger packet-wide validation, the attacker can alter the decision outcome itself.
Practical implication: enforce stronger packet validation and remove MD5-only trust assumptions from RADIUS authentication paths.
Why Access-Accept manipulation becomes a network access bypass
The critical failure occurs when a forged Access-Reject is rewritten into Access-Accept before the legitimate server response arrives. Because the RADIUS client evaluates the response as authoritative, authorization is granted even though the server never approved it. This is not credential theft in the classic sense. It is decision forgery, where the attacker changes the meaning of the authentication result rather than stealing the secret that created it.
Practical implication: treat response integrity as part of access control design, not as an optional protocol detail.
Why RadSec, Message-Authenticator, and EAP-TLS change the trust model
RadSec moves RADIUS traffic into TLS over TCP, which protects the channel from on-path manipulation. Message-Authenticator adds stronger packet validation across the full message, while EAP-TLS provides mutual authentication and cryptographically stronger access flows. These controls matter because they shift trust away from a weak legacy response hash and toward transport and session integrity. In practice, they reduce the chance that a forged packet can be accepted as a real authorization decision.
Practical implication: prioritise transport protection and mutual authentication where RADIUS still gates high-value access.
Threat narrative
Attacker objective: The attacker’s objective is unauthorized network access without needing the user password or shared secret.
- Entry occurs when the attacker gains on-path position between the RADIUS client and server and can observe or intercept authentication traffic.
- Escalation follows when the attacker crafts a forged Access-Accept response using MD5 collision techniques and packet attribute manipulation.
- Impact occurs when the network access device accepts the forged response and grants unauthorized access to the attacker’s device or user.
Breaches seen in the wild
- Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
- JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
RADIUS response integrity was designed for a network where message authenticity could be inferred from a shared-secret model. That assumption fails when an on-path attacker can forge the authorization outcome itself. The implication is that access control teams must stop treating legacy response checks as sufficient proof of identity or entitlement.
Access decisions become a governance problem when the protocol can be coerced into accepting a false result. In RADIUS, the control failure is not just weak cryptography, but the reliance on an authorization response that can be manipulated before the legitimate server reply arrives. Practitioners should recognise this as decision forgery, not only packet tampering.
Network access is part of identity governance, not a separate infrastructure afterthought. RADIUS still sits in front of VPNs, Wi-Fi, and other access paths that govern human and non-human connectivity. When the trust boundary is weak, IAM policy can be bypassed at the transport layer before higher-level controls ever engage.
Protocol-era trust debt: legacy AAA systems carry control assumptions that no longer survive modern on-path attack capability. That debt appears when integrity is anchored to an outdated response mechanism instead of end-to-end validation. The practical lesson is that older network auth stacks should be assessed as identity controls, not just connectivity plumbing.
RadSec and Message-Authenticator are not feature preferences, they are trust model corrections. The article shows why encrypted transport and full-packet validation matter when the response itself can be forged. For practitioners, the question is whether any high-value access path still depends on a trust model that an attacker can rewrite in transit.
From our research:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
- Only 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege.
- That same survey found organisations with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, which is why the 2026 Infrastructure Identity Survey remains the better forward lens on access governance.
What this signals
Protocol-level trust gaps will keep surfacing anywhere identity decisions depend on legacy transport assumptions. RADIUS is a reminder that access governance fails fastest where the integrity of the decision channel is weakest, not where the credential is weakest. Teams should review every network entry point as part of identity architecture, not just infrastructure design.
Static trust anchors create durable exposure, even in mature environments. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the broader pattern is that identity systems remain more brittle than most programmes admit. The same mindset that tolerates old credential models also tolerates old protocol trust models.
For practitioners, the next step is to connect access-path hardening with identity lifecycle governance. If a network access workflow still depends on a protocol that can be coerced in transit, then recertification and least-privilege reviews are incomplete until the transport path is also validated.
For practitioners
- Inventory every RADIUS dependency Map which VPN, Wi-Fi, and network access flows still depend on RADIUS and identify where an Access-Accept decision directly gates production access.
- Enable stronger response validation Require Message-Authenticator wherever the ecosystem supports it and verify that packet validation covers the full response, not just a legacy authenticator field.
- Move sensitive authentication paths to TLS transport Adopt RadSec for high-value network access paths so the RADIUS exchange cannot be manipulated by an on-path attacker in transit.
- Replace weak EAP dependencies Prioritise EAP-TLS for environments that need mutual authentication and stronger assurance than shared-secret-based response checks can provide.
- Reduce on-path exposure zones Segment access networks so only tightly controlled pathways can observe or relay RADIUS traffic, especially where legacy clients remain in use.
Key takeaways
- RADIUS response forgery shows how a network access decision can be manipulated even when the attacker never learns the shared secret.
- The practical scale of the problem is protocol trust, not just cryptographic weakness, because a forged Access-Accept can bypass access controls entirely.
- The control answer is to harden transport and packet validation, then reduce reliance on legacy RADIUS trust assumptions for high-value access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | RADIUS forgery exposes weak credential and protocol handling in access flows. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires stronger validation than a forgeable RADIUS response. |
| NIST CSF 2.0 | PR.AC-1 | Access control policy must account for forged authorization outcomes. |
Audit access protocols for weak integrity checks and replace legacy trust mechanisms where high-value access depends on them.
Key terms
- RADIUS response forgery: A protocol attack in which an attacker alters or fabricates a RADIUS reply so a network access device accepts a false authorization result. The weakness sits in the integrity of the response path, not in the user's password, which makes the attack especially dangerous for VPN and Wi-Fi access control.
- Message-Authenticator: A RADIUS attribute that strengthens packet validation by covering the contents of the message with a keyed hash. It is used to reduce the risk that an attacker can tamper with a response in transit and have it accepted as genuine by the client or network access device.
- RadSec: RADIUS over TLS, usually carried over TCP, which protects authentication traffic with transport-layer encryption and stronger integrity guarantees. For identity teams, it changes RADIUS from a packet that can be manipulated on path into a session that is much harder to intercept or forge.
- Network Access Device: The device that enforces access decisions at the edge, such as a switch, router, or VPN gateway. In RADIUS flows, the NAD is the system that trusts the server response and therefore becomes the enforcement point an attacker tries to deceive.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.
This post draws on content published by JumpCloud: RADIUS response forgery and the risks of CVE-2024-3596. Read the original.
Published by the NHIMG editorial team on 2025-06-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org